Rephrasing at EOF lets network attacker XSS HTTPS pages

RESOLVED FIXED

Status

()

RESOLVED FIXED
10 years ago
6 years ago

People

(Reporter: abarth-mozilla, Unassigned)

Tracking

({sec-low})

unspecified
x86
Windows XP
sec-low
Points:
---

Firefox Tracking Flags

(firefox-esr10 unaffected)

Details

(Whiteboard: [sg:low][fixed by the html5 parser], URL)

Attachments

(3 attachments)

(Reporter)

Description

10 years ago
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.
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.
(Reporter)

Comment 2

10 years ago
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.
(Reporter)

Comment 3

10 years ago
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.
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.
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.
Created attachment 367149 [details]
The complete response received from Barth's server before EOF
Created attachment 367150 [details]
small screen shot - alert dialog and FF window chrome
Created attachment 367151 [details]
small screen shot - subsequent window with long line of x's
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.
Whiteboard: [sg:low]
Is this still an issue with HTML5 parser?
(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.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Whiteboard: [sg:low] → [sg:low][fixed by the html5 parser]

Updated

6 years ago
status-firefox-esr10: --- → wontfix
status-firefox-esr10: wontfix → unaffected
Group: core-security
You need to log in before you can comment on or make changes to this bug.