Paid Advertising
web application security lab

Firefox DoS

With Blackhat impending, and given how many individual issues I’ll be discussing, I thought I should start posting them here. That and the fact that I’m quickly approaching my 1000′th post (which, if I have my way will be my last on means that I need to start wrapping up these issues into a neat little bow. I have 43 more, as of this post, so the clock is ticking. During my research for Blackhat I found a few things that were unrelated to the main content, and didn’t make sense to include in the presentation. So let’s start with a little user-initiated DoS that I was toying with. It’s using a bunch of frames and then throwing a recursive heap-spray into it. The heap-spray may or may not be a red-herring, but I got the best results when I used it compared to some of the other tests I ran.

On my system it gave me an odd set of errors. Typically with any type of recursion Firefox will eventually pop up the “A script on this page may be busy or it may have stopped responding.” error. This is no different, except for what script it thinks is misbehaving. The error alternates, but if I leave it running long enough sometimes I get “chrome://noscript/content/Main.js:2149″ sometimes I get “chrome://global/content/bindings/general.xml:0″ sometimes I get “file:///C:/Programe%20Files/Mozilla%20Firefox/components/nsContentPrefService:1012″ and so on… These may point to race conditions, memory overwriting or something equally bad. Perhaps someone with more time can do more with this, but it was kind of fun to play with. Anyway, please save your work before you try this, but here is the demo.

13 Responses to “Firefox DoS”

  1. The Rook Says:

    I have run your PoC, It defiantly brings Firefox to its knees but this doesn’t strike me as a memory corruption issue.

  2. RSnake Says:

    @The Rook - It could quite possibly not have any memory corruption issues, you’re right. I didn’t spend enough time on it to make an assessment, nor am I the right guy to do that, even if I did have the time.

  3. mr.The Says:

    Look at this (only opera and safari can load this page). Firefox and ie get full freeze. Chome freeze the tab.

    and this (russian).

  4. Lar Says:

    My Avast did manage to detect this, but it worked against Firefox quite effectively after I bypassed the warning

  5. malloci Says:

    Very interesting… I have done similar research which may apply to the current topic of discussion This poc requires the avg add-on to work but if the AVG Safe Search add-on is installed while running FF 3.6.3 on Vista, I am able to overwrite a memory location which is jmp’ed to by the AVG dll C:\Program Files
    I was able to trigger a DEP violation on Vista very reliably. Keep up the research rsnake I look forward to your next 43 post’s.

  6. Tom T. Says:

    Don’t you just love the fact that NoScript users get the message,
    “You must turn on JavaScript to see this demo”? … meaning that they’re default-protected from the attack.

    Whether you wish that everyone would use NoScript, or that no one would, I guess depends on whose side you’re on. :)

    Effective, but easy enough to close the browser with Task Manager and start a new session. The really nasty ones make you have to reboot. :)

  7. Wornstrom Says:

    Firefox does seem to misjudge what script is stuck every now and then, and it’s commonly part of NoScript that gets fingered. I’d guess that it just points at whatever script is currently active (or perhaps whichever has the most CPU time) after a given timeout, and your attack has the internal scripts doing enough work to get them misidentified as the problem on occasion.

  8. Wladimir Palant Says:

    Robert, there is no real issue here, it is simply that your demo causes a lot of different code in the browser to run. Eventually the browser notices that the code hangs and stops it - and it shows the line that is running *right now*, not the line that took most time. Which is quite likely a code line from NoScript or the browser itself. This isn’t a race condition or a memory corruption. Still, placing the blame is rather hard in this case.

  9. Giorgio Maone Says:

    As Wladimir said, this just means that Firefox noticed the UI thread running JavaScript code too long without yielding to process user input, and it’s giving user a chance to stop it.

    The interruption happening inside NoScript is unsurprising, since your PoC essentially initiates a huge number of requests in a tight loop (data: URIs get processed synchronously) and NoScript performs checks (for content blocking, XSS filtering, ABE and so on) on each request. In fact, NoScript implements also a safe-guard against interruptions of its code (caused either by user, like in this case, or by out-of-memory errors), automatically aborting the request(s) whose checks couldn’t be completed.

  10. RSnake Says:

    @All - thanks for the insights. I agree, that is probably what is happening. My understanding is that tight loops should be stopped, but in this case, it’s hundreds of tight loops, so stopping it seems like a harder task. Anyway, I thought people might find it interesting, and I agree, a good task manager and Noscript cures most ailing browsers. ;)

  11. xy Says:

    “”which, if I have my way will be my last on”"

    Why? Will you continue blogging at all?

  12. RSnake Says:

    @xy - You never know what the future will bring. I have a few small things I do here and there that are unrelated to that I’ll probably continue doing, but technical blogging about web application security is probably a thing for my past. There are lots of fresh minds out there who need their day in the spotlight. :)

  13. Wladimir Palant Says:

    Robert, I filed on the “unresponsive script” warning doing a bad job in this case and a bunch of others.