Open Bug 756494 Opened 12 years ago Updated 2 years ago

XMLHttpRequest event listeners can fire recursively and overflow the stack

Categories

(Core :: JavaScript Engine, defect)

13 Branch
x86
Windows XP
defect

Tracking

()

People

(Reporter: blubban, Unassigned)

References

(Blocks 1 open bug)

Details

(4 keywords, Whiteboard: [js:inv:p1])

Attachments

(3 files, 1 obsolete file)

Attached file die.html (obsolete) —
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20100101 Firefox/13.0
Build ID: 20120509070325

Steps to reproduce:

1. Create some XMLHttpRequests and attach some event listeners.
2. The event listeners must call alert(), or something else that does not return to JS but does return to the main loop.
3. The event listeners may be the same function; one listener per request is enough.
4. The event listeners must fire many times (52 to 55 for me; may vary for others, I think it's higher on 64bit machines). This can be done by either letting them fire many progress events, or running many requests.

The attached document does this in two ways (hundreds of load events, or a bunch of progress events). It is safe to load and reload; it doesn't run the naughty code until some links are clicked.

Crashes may be expanded to run malicious code, therefore I'm marking this security sensitive. If this is wrong, reversing it is easier than reversing an incorrect lack of security mark.


Actual results:

A bunch of message boxes appeared, as expected. Once I also saw some stack overflow errors in the error console, but I didn't look for this very much.

Then Mozilla Crash Reporter appeared.
(I hope I didn't spam it too much.)


Expected results:

A bunch of exceptions, a Sad Tab, or whatever. A crash is not desirable in any context.
Component: Untriaged → DOM
Product: Firefox → Core
QA Contact: untriaged → general
Attachment #625147 - Attachment mime type: text/plain → text/html
Could not reproduce with attached testcase on nightly builds on OS X 10.7.
Attached file Testcase, v2
I tested the testcase directly from the attachment on a Windows XP box, the same one I developed this testcase on. Button 1 calls the event handlers one after the other and doesn't do anything weird; the file upload method makes it die. A public copy I used for testing ( http://99.10.160.182/alcaro/die.html ) makes both testcases work. I suspect the filename change (die.html -> attachment.cgi) confused it.

I also tested on a Windows 7 box on the public copy of the document (too lazy to look up my Bugzilla password on that machine), and that has to be the weirdest state I have ever seen Firefox in. It's as if all JS disappeared, but the XUL kept running (the hover effects acted as expected, and I could edit the search and URL bars, but clicking them did nothing). Closing the Firefox window closed the window, but not the process; I had to kill it with the task manager. I also got a bunch of weird "[xpconnect wrapped nsIConsoleMessage]" notices in the error console at uneven intervals for some unobvious reason.

I also let one of my friends test it on Firefox 15.0, 64bit Linux. He got a bunch of message boxes, as expected, but no crash or other weirdness. Maybe the stack is bigger for 64bit processes?

Either way, here's a new testcase (also uploaded as the public copy). This one should crash more if it gets a group of files small enough to not throw progress events, and should work better when placed on URLs that aren't "die.html".
Attachment #625147 - Attachment is obsolete: true
Could you link to some of your crash reports please?  That may help figure out what is happening.
The stack is interesting here.  We've noticed that we've recursed too deep, but we exhaust the C stack when attempting to report the exception.
Assignee: nobody → general
Component: DOM → JavaScript Engine
QA Contact: general → general
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment on attachment 625382 [details]
Testcase, v2

I could swear I set this one as text/html when I submitted it. Fixing.

Either way, tested some more on Firefox 13.0b4, Windows 7 and XP. Testcase 1 seems fixed; I can't reproduce any crash on neither XP or 7. (It still lags a lot, though; I blame the transparency effects. But that's probably another bug.) However, I think this is just luck and that it will rebreak sooner or later.

Testcase 2 is improved, but not fixed. On Windows XP, it initially acted properly (not counting a couple of notices in the error console, see bug756494ec1.png). I cleared them out and started clicking OK on the alert()s. The result of this was a couple of [xpconnect wrapped nsIConsoleMessage]s appearing in the error console at uneven intervals, and all (other) JS died, as happened for me on 13.0b3 on Windows 7. The number of OK clicks needed to kill Firefox seems to vary; once it took ~5, once it took ~20. Firefox seems to return to a consistent and sane state if I close the tab while the alert()s are open.

On Windows 7, the JS died as in 13.0b3. I opened the error console after opening the second testcase this time for some invalid reason, and it was completely blank; not just "no errors", the buttons weren't there either. Only the standard window border existed. (I forgot taking a screenshot.)
Attachment #625382 - Attachment mime type: text/plain → text/html
Attached image Some more weird errors.
Whiteboard: [js:inv:p1]
Group: core-security
Keywords: crash, csec-dos, testcase
Assignee: general → nobody
Keywords: sec-other
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: