455100 - A tiny, malicious SVG file (using nested/recursive <use>/<def> elements) causes firefox to stall and use up the system's memory

Status: NEW

(Core :: SVG, defect)

Description

[Erik Bosman]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9) Gecko/2008061017 Firefox/3.0
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9) Gecko/2008061017 Firefox/3.0

Using SVG and xlink, it is possible to craft graphics which are rendered in exponential time relative to their size. This makes it very easy to stall firefox using only a tiny file. Additionally the SVG renderer seems to use exponential space too (presumably by precomputing the graph for fast re-rendering after zooming.) this causes firefox to allocate and use huge amounts of memory (on a 361 byte file.)

Reproducible: Always

Steps to Reproduce:
1. Visit http://www.cs.vu.nl/~ejbosman/death.svgz or a similarly crafted svg file

Actual Results:  
Firefox stalls, allocates huge amounts of memory. After a while, my system (Ubuntu Hardy) starts thrashing (preventable using ulimit of course,) becomes extremely unresponsive,

Expected Results:  
Rendering should not block menus/other tabs, if rendering takes too long, a message like the one for slow javascript programs should ask the user whether to continue.

The malicious SVG creates a huge tree of objects by recursively defining objects as groups of two links to the previous object,

Comment 1

[Mats Palmgren (inactive)]

Attachment: Reporter's testcase

Comment 2

[Bruce Rindahl]

Same behavior on Windows XP

Comment 3

[Brandon Mitchell]

See also Bug 514841, about 10 MB animated GIF images that quickly eat up several gigabytes of memory when rendering, causing Firefox to become especially unresponsive on computers with smaller RAM installations (page-file thrashing).

Comment 4

[Helder "Lthere" Magalhães]

Attachment: Slightly modified testcase

Original testcase, slightly cleaned up and with proper indentation.

Comment 5

[Helder "Lthere" Magalhães]

Attachment: Testcase which doesn't reproduce the symptoms (for comparison)

Test case, for comparison, which doesn't reproduce the symptom (at least, in my environment).

Comment 6

[Helder "Lthere" Magalhães]

(In reply to comment #2)
> Same behavior on Windows XP

Same behavior on Windows Vista SP2 using a nightly build [1].

I've made a few experiments and, at least for me, the symptom goes away after commenting the groups after (and including) the one with the "m" identifier. It seems that the exponential symptom is triggered around here: uncommenting a group at a time makes the browser halt (and consume memory) for a while more than with the previous group subset.

I've also tried adding the "a" identifier to the existing circle, in order to check if this was only reproducible with broken links but no: making the target resource resolvable or not doesn't lead to a different result.


(In reply to comment #3)
> See also Bug 514841, about 10 MB animated GIF images that quickly eat up
> several gigabytes of memory when rendering

Sorry, Brandon, but this issue isn't apparently related with rendering, it's related with resource locating dependencies. ;-)


[1] Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20091029 Minefield/3.7a1pre (.NET CLR 3.5.30729)

Comment 7

[Erik Bosman]

Since firefox 4, SVG is now also supported in <img> tags, this makes sites that
allow cross-linked PNGs (think forums/wikis) vulnerable to a client-side DOS.

See:

http://pizzadoos.com/forcesvg/death.html

(http://pizzadoos.com/forcesvg/death.png really is an SVG, with a forced image/svg+xml mime-type to demonstrate that checking on the extension by the webdeveloper won't help.)

Comment 8

[Wayne Mery (:wsmwk)]

(In reply to Helder "Lthere" Magalhães from comment #4)
> Created attachment 409337 [details]
> Slightly modified testcase

tested for grins. The resulting crash is 
bp-aafb91ff-9855-4fca-b338-960852140718
 OOM | large | mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xrealloc | nsTArray_base<nsTArrayInfallibleAllocator, nsTArray_CopyWithMemutils>::EnsureCapacity(unsigned int, unsigned int) | nsTArray_Impl<nsIContent*, nsTArray...

Comment 10

[Manish Goregaokar [:manishearth]]

I'm not certain, but I think that this bug  also poisons the Fx cache making it slow on startup. 


Could this please be fixed?

Comment 11

[Nicolas Belleville]

I have worked on this bug and here is what I've found.

The growth of memory happens during reflow.
To interrupt it, ProcessHangMonitor appears to be a good candidate. Indeed, it is already used for slow scripts and plugin hang. 
To use it, it is necessary to add a new hangType (SLOW_SVG_REFLOW for instance, see the diff file joined), and adapt several ProcessHangMonitor methods (the diff is probably not enough, and there are probably others modifications to do). 
I think it might be quite feasible to interrupt the growth during CreateAnonymousContent (https://dxr.mozilla.org/mozilla-central/source/layout/svg/nsSVGUseFrame.cpp#238), as this method is called a lot during the reflow of this file (but I did not manage to do it). 
The best solution would probably be to detect the growth of memory, but a timeout can be used too. WindowMemoryManager is probably useful to get the memory use of the process, but I didn't understand how it works. Otherwise, memory use can be accessed like shown in the code attached, but such methods are OS dependant (in this diff, it is done for linux and stops the growth by killing the process without any prompt). 
Once the growth is detected, we should show a dialog to the user, like it is done here for slow script : https://dxr.mozilla.org/mozilla-central/source/js/xpconnect/src/XPCJSRuntime.cpp#1480 
Then, if the user wants to stop the loading process, we should use the ProcessHangMonitor TerminateProcess method to stop it.
You will also find attached a new test case which doesn't increase the RAM as much as the original one (stops after a 1.6Go increase), which can be useful to see the RAM increasing “without” danger, and a gdb backtrace taken during the reflow.
Please note that the code that causes the increase is done in an independent process called Web Content in nightly, due to e10s implementation. For that reason, to see in gdb what is executed we have to attach it to this new process.

See my comments below for attachments

Comment 12

[Nicolas Belleville]

Attachment: new testcase less dangerous

Comment 13

[Nicolas Belleville]

Attachment: code to begin ProcessHang adaptation, and to stop the growth (only works in Linux)

Comment 14

[Nicolas Belleville]

Attachment: gdb backtrace during the growth of RAM

Comment 16

[Andrei Purice]

This issue is still reproducible for me on the latest versions of Firefox Nightly 87.0a1 (2021-02-04), beta 86.0b6 and release 85.0 on Windows 10, Ubuntu 20.04 and MacOS 10.15.
Updating the flags accordingly.

Comment 20

[Kai Engert [:KaiE:]]

It would be good to find a fix for this bug.
I don't have the skills myself to find a fix, I asked the claude AI for an idea.

It suggested to measure the complexity of the SVG rendering, and abort rendering when a limit is reached.
I'll attach a patch it made.

With this patch, rendering of the attached file is aborted after a few seconds.
A pref is introduced to control the limit.

Would this approach be reasonable, or could it serve as an inspiration for a fix for this bug?

Comment 21

[Kai Engert [:KaiE:]]

Attachment: WIP: Bug 455100 - Limit allowed number <svg:use> expansions to avoid resource exhaustion.

Comment 22

[Emilio Cobos Álvarez [:emilio]]

If you want to track the expansion limit, you can do that in SVGUseElement rather than Document, that'd be more reliable because otherwise you get into correctness issues on long-running sessions that can hit that limit legitimately.

Comment 23

[Kai Engert [:KaiE:]]

(In reply to Emilio Cobos Álvarez [:emilio] from comment #22)

If you want to track the expansion limit, you can do that in SVGUseElement rather than Document, that'd be more reliable because otherwise you get into correctness issues on long-running sessions that can hit that limit legitimately.

The problem with that is each SVGUseElement then gets its own limit. If a SVG contains multiple uses, it seems we get many counters, IIUC?

Comment 24

[Emilio Cobos Álvarez [:emilio]]

Use elements already track their original element, you can just track in the outer one.

Comment 25

[Kai Engert [:KaiE:]]

I'll submit a thought that I wanted to post as a follow up to my comment 23 below.
This was before I looked at your new comment 24.

What do you think about this modified approach, which can be seen in the attached patch.

I think your worry was specifically about a document into which multiple SVGs may be loaded over time, which may happen in long living documents. This might happen in Firefox, but it seems unlikely this would happen in Thunderbird.

It seems it can be detected whether an SVG file is loaded separately, or whether it's loaded inline.

The suggestion is that the limit is always enforced whenever the SVG is loaded by itself.

When an SVG is loaded inline into a document, the suggestion is to disable the limit in Firefox, but still enforce a global limit in Thunderbird.

Comment 26

[Emilio Cobos Álvarez [:emilio]]

That seems more complicated and hackier than just doing the right thing.

Comment 27

[Robert Longson [:longsonr]]

Can't I just put a <use> in a <iframe> in a <foreignObject> in a <use> in an <iframe>.... to trivially get round this latest approach? The iframe elements create separate documents so the counter would then be one per document but you'd still have a problem.

Comment 28

[Emilio Cobos Álvarez [:emilio]]

Yeah though iframes have a limit IIRC.

Comment 29

[Emilio Cobos Álvarez [:emilio]]

Still you could add like 10000 sibling iframes or something

Comment 30

[Kai Engert [:KaiE:]]

Does that mean there is no reasonable fix for this bug?

Would you say this is a wontfix bug?

Comment 31

[Robert Longson [:longsonr]]

Well there's always bug 1477214

Comment 32

[Kai Engert [:KaiE:]]

(In reply to Robert Longson [:longsonr] from comment #31)

Well there's always bug 1477214

I can't access it.