Open Bug 1297206 Opened 9 years ago Updated 3 years ago

DoS loading a SVG image that consumes all your memory

Categories

(Core :: SVG, defect, P3)

48 Branch
defect

Tracking

()

Tracking Status
firefox48 --- affected
firefox51 --- affected

People

(Reporter: gustavo.grieco, Unassigned)

Details

(7 keywords, Whiteboard: [sg:dos])

Attachments

(2 files)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0 Build ID: 20160806094113 Steps to reproduce: I'm using Firefox 48 in ArchLinux (x86_64). Just load this svg image: https://dcc.fceia.unr.edu.ar/~ggrieco/oom.svg (518K) Actual results: It will cause Firefox to consume all your memory. It can take a few minutes (5 or 6 in a desktop computer with 16GB) and the image won't load. Firefox will crash/abort or it will be killed by the OS (for instance, in ArchLinux). Expected results: Firefox should not eat all your memory. This kind of DoS is particulary interesting since it will only requires a small image to attack a large amount of browsers. This test case was discovered using QuickFuzz.
I can reproduce on OS X.
Group: firefox-core-security → core-security
Status: UNCONFIRMED → NEW
Component: Untriaged → SVG
Ever confirmed: true
OS: Unspecified → All
Product: Firefox → Core
Hardware: Unspecified → All
(DoS bugs don't need to be hidden as security-sensitive; we only hide bugs that might lead to arbitrary code execution, serious privacy leakage, that sort of thing. Looks like I don't have privileges to remove that classification, though; dveditz, would you mind removing that?)
Flags: needinfo?(dveditz)
Group: core-security
Flags: needinfo?(dveditz)
Keywords: crash
Whiteboard: [sg:dos]
On my Mac this is more of a hang -- it's been running for a half hour and is using 38Gb of virtual memory but shows no signs of stopping any time soon. The real memory climbed for a bit at first but has dropped to just over 1Gb and seems happy/stable there. I suppose it'll get killed eventually.
Keywords: hang
The problem appears to be related to the use of xlink:href. If you remove the xlink:hrefs, the file renders almost immediately sed -e 's/xlink:href="[^"]*"//' <oom.svg >oom-noxlink.svg It's also possible to create a small reproducer where the render time/memory use grows exponentially with the number of xlink:hrefs. See http://pastebin.com/raw/iYVA5Bnu
Keywords: perf
Priority: -- → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: