Closed Bug 667907 (CVE-2011-3656) Opened 8 years ago Closed 8 years ago

Possible XSS via HTTP 0.9 errors and content-sniffing


(Core :: Networking: HTTP, defect, P1)




Tracking Status
firefox7 - wontfix
firefox8 + fixed
firefox9 + fixed
firefox10 + fixed
blocking1.9.2 --- .24+
status1.9.2 --- .24-fixed


(Reporter: gerv, Assigned: bzbarsky)



(Keywords: verified1.9.2, Whiteboard: [sg:moderate][qa-] cross-browser, embargo until Dec 28, 2011)


(2 files)

[This is from the MB-Secissues mailing list.]


We just fixed an issue in Opera 11.50, but as we noticed a few other browsers are vulnerable, we did not post any details. "Fixed a moderately severe issue. Details will be disclosed at a later date."

The issue is an old one. Some non-HTTP protocols running on a server might respond to HTTP requests with an error message, and return (parts of) the incoming request. If web browsers content-sniff data returned withouth HTTP headers, an attacker might be able to send data to such a service, and have the server return an error which the browser interprets as HTML/JS. This opens up for XSS.

HTTP version 0.9 (which is still in use in some rare cases) does not send HTTP headers, so we still content sniff on ports 80 and 443. Our fix is to stop content sniffing on non-standard ports. We require either an explicit HTTP/1.* header (then we will content sniff), or a Content-type. There are of course other fixes too, like not running scripting, even if one does content sniff. Our test case tests our implementation, so it might be some other browsers are not vulnerable, even though I have listed them as failing on our TC.

We will withhold information for now, if nobody tells us otherwise, we will publish full details next time we clean up in our unpublished advisories, at least half a year from now. If anyone wants us to hold off longer, or would like more info, please let us know.

Failing on our test case:
Opera 11.11
Chrome 12.0
Safari 5.0.4
Firefox 4.0.1
Internet Explorer 8.0

Passing on our test case:
Opera 11.50

This has been tested well, and we have found no compatibility issues with this.

Sigbjørn Vik
Quality Assurance
Opera Software
MB-SecIssues mailing list
When they say they don't content sniff, what behavior did they implement, exactly?

I would have no problem with not sniffing HTTP 0.9 document types on non-default ports, I think; the obvious option is to treat them as application/octet-stream.

But note that this does NOT help with <script>s, because those ignore the content-type anyway.  So are they only protecting against sniffing as HTML and not worrying about <script>s embedding such content?  Or something else?

It's hard to evaluate what needs doing here about a better idea of what their attack scenario is and what their proposed change is.
The contact at Opera is Sigbjørn Vik <>. I don't know any more than what's in the email :-)

OK, I mailed him.
Specifically what I sent:


This mail is about your post to MB-Secissues about HTTP 0.9 and sniffing.  There's a Gecko bug tracking this at (security-sensitive, of course; I can add you to the bug if you have a bugzilla account).

I'm trying to understand the extent of the problem here.  Your description of Opera's mitigation is that you simply don't perform type sniffing on such responses, but <script> tags ignore the type anyway.  So are you just protecting against using an HTTP 0.9 response as HTML in this situation but not against using it as a script?

What XSS vectors are you concerned with, exactly?  For a non-default port, a page would not typically run with the origin of regular (port 80/443) pages on the same hostname, right?  So while you can inject script into the page and run it with the origin "http://targetsite:weirdport", what issues does that cause?  I suppose it can circumvent XHR same-origin restrictions?

The other question I had is what your mitigation actually does.  You don't sniff the type.  Does that mean you treat it as application/octet-stream?  Or something else?
On MB-SecIssues, Adam Langley of Google asked:

> Is there a new, specific, cross-protocol attack here or is this a
> general mitigation?

and Sigbjørn replied:

This is a general mitigation, we have not done any research into which protocols/applications might be abused this way. 

Reply to my mail too:

1) "Correct. Scripts in an HTML file will be executed in the domain of the HTML
    file. Plain scripts execute in the domain of the HTML file which includes
2) "You are right that the same origin policy typically protects against cross
    port vectors, though the web is not used to relying on this. For instance
    cookies do not abide by ports, and you mention XHR. I don't think the
    origin header takes this into consideration either. If you start looking
    into other technologies (e.g. plugins, SVG, Xpath, cached site policy
    files, application cache ...), I am sure you will find other examples. For
    practical purposes, getting cookie access is mostly equivalent to XSS.
    Apologies if my original mail was unclear."
3) "text/plain"

Doing what Opera did should not be difficult if that's the way we want to go.  Thoughts?
It's probably not a common scenario, but large/popular domains with cookies worth stealing are precisely the ones who might have a non-web server running on one of their public machines somewhere. Maybe on a non-banned port.
Whiteboard: [sg:high]
Unfortunately, I can't seem to run a test server on port 80, so can't test the "default port" codepath...
Attachment #543064 - Flags: review?(jduell.mcbugs)
Assignee: nobody → bzbarsky
Priority: -- → P1
Whiteboard: [sg:high] → [need review][sg:high]
Comment on attachment 543064 [details] [diff] [review]
This is what Opera seems to have done

Review of attachment 543064 [details] [diff] [review]:
Attachment #543064 - Flags: review?(jduell.mcbugs) → review+
Whiteboard: [need review][sg:high] → [need landing][sg:high]
the content type of a http/0.9 is supposed to be html, not plain.

I don't know that it matters, without content-sniffing its pretty much just not going to work no matter what for somebody.
> the content type of a http/0.9 is supposed to be html, not plain. 

Right, but that gives the XSS issue.

> without content-sniffing its pretty much just not going to work

Indeed.  That's the effect of this patch.  HTTP/0.9 on non-default ports (80 for HTTP and 443 for HTTPS) will just show the text and that's it.
Flags: in-testsuite+
Target Milestone: --- → mozilla8 

dveditz, is this something we want to backport to 3.6?
Closed: 8 years ago
Resolution: --- → FIXED
Whiteboard: [need landing][sg:high] → [sg:high]
blocking1.9.2: --- → ?
Is there any reason not to take this on 3.6.x?
blocking1.9.2: ? → .24+
> Is there any reason not to take this on 3.6.x?

The only obvious one is compat risk, but we haven't run into issues with it, and I would judge it to be pretty low.
Comment on attachment 570047 [details] [diff] [review]
1.9.2 branch fix

Requesting 1.9.2 approval.
Attachment #570047 - Attachment description: 9.2 branch fix → 1.9.2 branch fix
Attachment #570047 - Flags: approval1.9.2.24?
Comment on attachment 570047 [details] [diff] [review]
1.9.2 branch fix

Approved for Please land on releases/mozilla-1.9.2 default branch asap. Thanks!
Attachment #570047 - Flags: approval1.9.2.24? → approval1.9.2.24+
What is the manual STR for this or is the new 1.9.2 unit test sufficient to test this for 1.9.2 verification?
The other option is to set up a web server that serves something that looks like HTML on a non-standard port using HTTP 0.9 and see whether a script in that HTML runs...
Thanks, Boris! ;-)

I'm calling this verified1.9.2 based on the script.
Keywords: verified1.9.2
This was rated "sg:high" based on the "XSS" claim, but a server running something that we think is maybe HTTP 0.9 is on a different origin (scheme-host-port) than the site's actual website by definition. There are risks here (spoofing, grabbing non-httponly domain cookies) but it's not universal XSS and doesn't meet the "high" bar for me.

Please correct if I'm missing a potential attack that's more severe.
Whiteboard: [sg:high] → [sg:moderate]
Any plans to assign CVE to this?
Alias: CVE-2011-3656
Whiteboard: [sg:moderate] → [sg:moderate] cross-browser, embargo until Dec 28, 2011
Whiteboard: [sg:moderate] cross-browser, embargo until Dec 28, 2011 → [sg:moderate][qa+] cross-browser, embargo until Dec 28, 2011
Trusting this is fixed for other versions of Firefox just as Al did for 1.9.2. If someone is already set up to verify this fix re: comment 21, please do so.

Whiteboard: [sg:moderate][qa+] cross-browser, embargo until Dec 28, 2011 → [sg:moderate][qa-] cross-browser, embargo until Dec 28, 2011
Group: core-security
Depends on: 728236
You need to log in before you can comment on or make changes to this bug.