483023 - Rephrasing at EOF lets network attacker XSS HTTPS pages

Status: RESOLVED FIXED

(Core :: DOM: HTML Parser, defect)

Description

[Adam Barth]

Imagine that an active network attacker is trying to attack an HTTPS page.  The HTTPS has an XSS filter that lets the attacker injecting the following HTML:

<img alt="><script>alert(42)</script>xxxxxxxxxxxxxxxxxxxxxxx" src="...">

This HTML passes the site's XSS filter because it is not an XSS attack.  Now, when the HTML page is sent to the user, the active network attacker (or DNS poisoner) interrupts the transmission during the xxxxxxxx bytes.  Firefox sees the EOF and decides to execute the attacker's script, leading to XSS.

Here's an example showing that the script runs:

http://webblaze.org/abarth/tests/eof/firefox.html

This bug isn't a huge problem, but it's probably worth fixing.  Note that Safari and Chrome do not run the script.  I'm not sure how the HTML 5 parser behaves in this case.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

That fact that it works with http is no indicator that it will work with 
https.  In https, data is sent in "records", which are either successfully
received in their entirety or not received at all, so the attacker cannot
arbitrarily cut off the data between two arbitrary characters of its 
choosing in the server's output.

Also, with SSL, a premature EOF generates an error.  An EOF on the underlying socket that is not preceded by SSL's special EOF record is reported to the
higher layer as an error, not as an ordinary EOF.  Unless FF is ignoring that 
error, FF should know that the page load was not entirely secure.

Comment 2

[Adam Barth]

Oh, interesting.  Regarding records, that mitigates the issue to some extent, but the attacker can always pad xxxxxxx until it crosses a record boundary.  Regarding special EOF versus ordinary EOF, I haven't tested that directly.  I'll try to set up a test case for that.

Comment 3

[Adam Barth]

Here is a new test case:

https://webblaze.org/abarth/tests/eof/firefox.php

This page has a lot more xxxxx and then goes to sleep for a long time.  I loaded this page in Firefox 3 and then shut off my wireless network connection.  Once I did that, the script executed.  Right after the script executed, the page got replaced with the following message:

"Connection Interrupted
The connection to the server was reset while the page was loading.
The network link was interrupted while negotiating a connection. Please try again."

So, it looks like you're right that we're catching the premature EOF as an error, but we're not doing it fast enough to stop the attacker's script from running.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

I repeated this test, but in a way that causes Firefox's SSL socket to get
an ordinary EOF (a TCP FIN) rather than an error termination.  

The results I got were:
1) an alert dialog, indicating that the script had been executed, 
and when I clicked OK, I got
2) a page containing a long line of "xxxxxxxxx..."

I did NOT get any error about connection being interrupted (presumably
because the connection got a TCP FIN).  So, I confirm this bug.

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

Note: my test did NOT cause an SSL EOF record to be sent before the TCP FIN, 
so it was a true connection truncation that resulted in EOF, not timeout or 
RST.

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

Attachment: The complete response received from Barth's server before EOF

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

Attachment: small screen shot - alert dialog and FF window chrome

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

Attachment: small screen shot - subsequent window with long line of x's

Comment 9

[Daniel Veditz [:dveditz]]

This is a quirks mode behavior we can probably get rid of. If there are any subsequent quotes on the page then the mismatched quote becomes matched and this injection doesn't work. Instead, in the mismatched case we should just eat to EOF rather than supplying an assumed missing quote before the closing angle bracket.

(In reply to comment #0)
> Note that Safari and Chrome do not run the script.

But IE does.

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

Is this still an issue with HTML5 parser?

Comment 11

[Henri Sivonen (:hsivonen)]

(In reply to Olli Pettay [:smaug] from comment #10)
> Is this still an issue with HTML5 parser?

No, by design. If the stream ends inside the run of xxxxx, the img start tag token is incomplete and gets dropped. Furthermore, EOF never causes reparsing with different tokenization.