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)
Tracking
()
NEW
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.
Comment 1•9 years ago
|
||
I can reproduce on OS X.
Group: firefox-core-security → core-security
Status: UNCONFIRMED → NEW
status-firefox48:
--- → affected
status-firefox51:
--- → affected
Component: Untriaged → SVG
Ever confirmed: true
OS: Unspecified → All
Product: Firefox → Core
Hardware: Unspecified → All
Comment 2•9 years ago
|
||
(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)
Comment 3•9 years ago
|
||
Updated•9 years ago
|
Comment 4•9 years ago
|
||
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
Updated•8 years ago
|
Priority: -- → P3
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•