420568 - Malicious server can hang browser via synchronous XMLHttpRequest request

Status: RESOLVED DUPLICATE of bug 190313

(Firefox :: General, defect)

Description

[C William Underwood]

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:1.8.1.6) Gecko/20071008 Ubuntu/7.10 (gutsy) Firefox/2.0.0.6''', '''Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12'''

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(); 
    request.open("get", "hangUrl", false); 
    request.send(null);
}
window.addEventListener('load', function() {setTimeout('hang()', 10)}, false);

Comment 1

[C William Underwood]

Attachment: 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).

Comment 2

[Martijn Wargers (dead)]

Duplicate of bug 190313?
Reporter, does it work all right for you on trunk?

Comment 3

[C William Underwood]

'''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):
        time.sleep(10)
        yield ' '

Comment 4

[C William Underwood]

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

[C William Underwood]

I have a test server running at http://cwillu.com:8080/ .  That url should expose the problem, and I'll try to leave it up for a few hours.

Comment 6

[Martijn Wargers (dead)]

(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

[C William Underwood]

Looks like the trickle mentioned above isn't necessary (not terribly suprising).

Comment 8

[Daniel Veditz [:dveditz]]

I can't realistically see anyone backporting the Thread Manager redesign (bug 326273) to Firefox 2.