Malicious server can hang browser via synchronous XMLHttpRequest request




11 years ago
11 years ago


(Reporter: cwillu, Unassigned)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: [sg:nse dos])


(1 attachment)



11 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3) Gecko/2008021416 Firefox/3.0b3
Build Identifier: '''Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20071008 Ubuntu/7.10 (gutsy) Firefox/''', '''Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20080201 Firefox/'''

Issuing a synchronous XMLHttpRequest to a 'streaming' resource that doesn't actually send data nor close the connection will hang all browser windows. 

Reproducible: Always

Steps to Reproduce:
1.  Create and host a page that issues a synchronous XMLHttpRequest to a particular url in the onload handler with a timeout.
2.  Make the above url backed by a script which doesn't send a content-length header (streaming response), and which doesn't close the connection.
3.  Visit the page create in (1.)
Actual Results:  
All browser windows (including chatzilla windows, etc) hang with no gui updates as long as the server keeps the connection open.  The user has no means of interrupting the connection other than killing the browser window via os specific means.  

If the server closes the connection before the user kills the browser, then the browser regains full functionality:  the ui unfreezes and the user can continue as normal.

Expected Results:  
The ui should remain responsive.  Ideally, the escape key would break the connection, but regardless, the connection should not hold the browser captive.

This occurs under linux and windows machines, although it _doesn't_ occur under firefox 3beta3.

The specific code I'm using is included, although the server side code won't be directly usable.  The core piece of html seems to be:

function hang() {
    var request = new XMLHttpRequest();"get", "hangUrl", false); 
window.addEventListener('load', function() {setTimeout('hang()', 10)}, false);

Comment 1

11 years ago
Created attachment 306865 [details]
html file containing exploit (actually a template, but it works as is)

I'll post a better example, but the idea should be visible even if the effect isn't (depends on server side).
Duplicate of bug 190313?
Reporter, does it work all right for you on trunk?

Comment 3

11 years ago
'''Server side code

This won't be directly useable, but the intent should be visible.  Still playing with the code, the single byte trickle may not be necessary.


def waitForChange(self, obj, path, hash=None):
    for interval in range(60 * 60):
        yield ' '

Comment 4

11 years ago
Martijn, it works fine in firefox 3 beta 3, I haven't tried a trunk 2.whatever build if that's what you mean.


Comment 5

11 years ago
I have a test server running at .  That url should expose the problem, and I'll try to leave it up for a few hours.
(In reply to comment #4)
> Martijn, it works fine in firefox 3 beta 3, I haven't tried a trunk 2.whatever
> build if that's what you mean.

Ok, thanks for testing, yeah, that's what I meant.
So I think this is indeed a duplicate of bug 190313. It was something that is fixed for Firefox 3.

Comment 7

11 years ago
Looks like the trickle mentioned above isn't necessary (not terribly suprising).
I can't realistically see anyone backporting the Thread Manager redesign (bug 326273) to Firefox 2.
Group: security
Last Resolved: 11 years ago
Keywords: hang
Resolution: --- → DUPLICATE
Whiteboard: [sg:nse dos]
Duplicate of bug: 190313
You need to log in before you can comment on or make changes to this bug.