438337 - Firefox DoS - tight JS loop in onload handler

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, defect, P5)

Description

[Kathleen :Brade]

Attachment: Small HTML page that has tight JS loop (should eventually stop)

I came across an evil web page while developing and testing a new extension.  This evil page has a variety of attacks including Denial of Service for the browser.  I've found ways to address most of the attacks but I'm not sure how to address a tight JS loop.  Timers are not fired, the page does not complete loading, and Firefox does not display the "A script on this page may be busy..." prompt.

All Platforms.  Tested on Linux, Mac, Windows; Firefox 2.0.0.14 and Firefox 3rc2.

Ideally I could add a hook that would allow me to detect this situation and kill the script, close the page, or load a different URL.  Better yet, the JS engine would just detect that it is in an infinite loop and break itself out of it or at least allow other code to run so the Firefox UI can update itself, etc.

Comment 1

[Jesse Ruderman]

Client hangs are not considered "denial of service bugs", and they're a dime a
dozen, so I'm making this bug public.

This is probably a dup of an existing bug report, such as bug 380806.  And I think you'll find that without the innerHTML-setting inside the loop, you get a slow-script dialog.

Comment 2

[Brendan Eich [:brendan]]

This is in any event not a JS engine bug. SpiderMonkey monitors loops (both interpreted and in costly native methods) and calls the DOM to measure time and put up a slow script dialog when too much wall-clock time has passed.

/be

Comment 3

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Comment 5

[Andrew McCreight [:mccr8]]

I tried this just now (admittedly on a computer likely vastly more powerful than any available in 2008), and the browser remains responsive throughout. Thanks to e10s, the UI runs in a separate process, so you should be able to close or switch tabs while it is running, and thanks to Fission the attacker's code can only overload the attacker's process, so busy loops like this in content don't seem like a big deal any more.