Paid Advertising
web application security lab

Quicky Firefox DoS

Well, it turns out I am speaking at Blackhat after all - plus I have an OWASP preso to do tomorrow. That makes five presos in 6 days. Shoot me now. Anyway, I was playing around with Firefox today and accidentally found a super tiny DoS for Firefox that reminded me of my childhood. Remember that math puzzle where you put one penny on one square and then two on the next and four on the next and so on? Clearly that would amount to more money than you could realistically have when you really think through it, but kids have a hard time wrapping their heads around it. This is sort of similar, except it’s not geometric, it’s linear, which was surprising that it caused Firefox so much pain. I had just assumed the JS engine in Firefox would have said that it’s running too tight of a loop and throw the “running too slow” prompt at worst - or just finish at best since it doesn’t look all that complicated:

var a;

I let this run for 10 minutes on a decent sized test machine and it never finished - I had to kill the process. Yeah, I know there are a million ways to DoS browsers, this one was just surprising because I honestly didn’t think it could. Anyway, if I don’t post before then, see you in Vegas!

23 Responses to “Quicky Firefox DoS”

  1. Stephen Tung Says:

    oh,that’s funny
    Firefox has some similar ting DoS bugs that can crash the browser already

  2. Shawn Lauriat Says:


    Note: While Safari gave me the long-running-script prompt for this, it failed to actually stop the script from taking over the browser about ten minutes after telling it to stop the script. I got tired of hearing my MacBook Pro impersonate a jet engine and force quit at that point.

  3. Hussein Nasser Says:

    Really Interesting,

    I never seen a browser who don’t prompt this message”very slow script is running!”

    This script does it!

    We won’t use it but good thing to learn

  4. rvdh Says:


  5. kuza55 Says:

    Ummm, I think you’ll find that you meant to say either exponential or geometric, rather than logarithmic, and linear, rather than geometric, just saying.

  6. RSnake Says:

    @rvdh - yes but I’m not spinning infinitely. I’m only iterating 65k times - I can see why yours would cause Firefox to spin for minutes on end, but not my example.

    @kuza55 - yea, thanks.

  7. dee Says:

    I had the same response as Shawn from IE8. It offered to kill the script but didn’t.

  8. dee Says:

    And since a.length increases exponentially with i, is it not geometric?

  9. mall0c(i); Says:

    I like the idea of a browser DoS… so, I thought I might add some more code to the mix. Not of much use, but it is still fun to play with.


    var str1=”";

  10. mall0c(i); Says:

    I like the idea of a browser DoS using web workers.
    Using web workers

    Here is some sample code:


    var worker = new Worker(”work.js”);
    // Watch for messages from the worker
    worker.onmessage = function(event)
    // The message from the client:
    document.getElementById(”result”).textContent =;


    onmessage = function(event){
    dos = [];
    while(1) {
    dos[] = new Worker(’work.js’);
    dos[].onmessage = function(event) {
    //dos[–] = new Worker(’work.js’);

  11. stranger Says:

    It’s clearly quadratic.

  12. RSnake Says:

    @dee - odd, my test on IE8.0 allowed me to kill it almost immediately. Not sure why it would be different on our two browsers. Maybe it’s a factor of available memory or something. And I don’t think it’s exponential since it’s just adding one character at a time. That would be linear.

  13. dee Says:


    Here’s a screen grab from procexp.exe

    “And I donít think itís exponential since itís just adding one character at a time. That would be linear.”

    Yeah, I conflated the code with some other code in my head. Another embarrassing example of why I shouldn’t try to work and play at the same time.

  14. stranger Says:

    RSnake, string length grows linearly but it’s written every time and that gives quadratic growth. At first, only 0 is written, then 0,1, then 0,1,2, etc. Full number of written characters after n iterations is about n^2/2.

  15. RSnake Says:

    @stranger - gotcha, that makes more sense (because it’s being written). I guess, 2 billion chars might take a while to output.

  16. ChosenOne Says:

    terminates nicely on an i7 with 12gb ram. (not mine, but reported by a friend)

  17. Picci Says:

    It’s just a matter of computational power vs time, if you stick in a larger number of iterations or make it grow faster (either one will do) it’ll take years on any machine…

    What I don’t get is: why does it fail to kill the script after the prompt?

  18. Kyo Says:

    Been there. I’ve had even more reasonable scripts DDoS my browsers. I was just coding casually (it’s been a long time since I did JS, so I can’t remember what it was now), doing something with popups, I don’t think there was even a loop in there, and BAM


  19. Kyo Says:

    meant to write DoS first time around there. Stupid laptop keyboard

  20. ritz Says:

    how about


    doubles the string every iteration.

    for more fun, try DOM objects instead of strings, use cloneNode to duplicate, append to itself as child (does it recursively dupe the entire subtree?). that should fuck up a browser pretty good.

    brings me to another idea, would it be possible to use event bubbling to set up an escalating chain reaction in DOM event handlers?

  21. Gareth Heyes Says:

    testing your wordpress :)

  22. XaDoS Says:

    oh .. good
    and this? it’s like yuor script. freeze FF and i have to kill the process :)


    var x=String.fromCharCode(120);
    var a=”";
    var b=”";

  23. tts Says:

    My guess is that the string.concatenation function is the culprit. It will be native code that is running, trying to create a ridiculously long string, each time getting ridiculously longer. By the time the script is running long enough for the browser to realise that its a slow-running script, the string will most likely be massive enough to tie up the native processing so that the javascript itself is not causing the slow-down.

    Just a thought.