Closed
Bug 438337
Opened 16 years ago
Closed 2 years ago
Firefox DoS - tight JS loop in onload handler
Categories
(Core :: DOM: Core & HTML, defect, P5)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: Brade, Unassigned)
Details
(Keywords: hang, Whiteboard: DUPEME)
Attachments
(1 file)
631 bytes,
text/html
|
Details |
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•16 years ago
|
||
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.
Group: security
Comment 2•16 years ago
|
||
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
Assignee: general → nobody
Component: JavaScript Engine → DOM
QA Contact: general → general
Whiteboard: DUPEME
Comment 3•6 years ago
|
||
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.
Priority: -- → P5
Assignee | ||
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
Comment 4•2 years ago
|
||
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.
Severity: major → --
Comment 5•2 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•