Last Comment Bug 667907 - (CVE-2011-3656) Possible XSS via HTTP 0.9 errors and content-sniffing
: Possible XSS via HTTP 0.9 errors and content-sniffing
[sg:moderate][qa-] cross-browser, emb...
: verified1.9.2
Product: Core
Classification: Components
Component: Networking: HTTP (show other bugs)
: unspecified
: All All
: P1 normal (vote)
: mozilla8
Assigned To: Boris Zbarsky [:bz] (still a bit busy)
: Patrick McManus [:mcmanus]
Depends on: 728236
  Show dependency treegraph
Reported: 2011-06-28 08:02 PDT by Gervase Markham [:gerv]
Modified: 2012-05-17 00:07 PDT (History)
13 users (show)
bzbarsky: in‑testsuite+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

This is what Opera seems to have done (3.69 KB, patch)
2011-06-29 22:11 PDT, Boris Zbarsky [:bz] (still a bit busy)
jduell.mcbugs: review+
Details | Diff | Splinter Review
1.9.2 branch fix (3.74 KB, patch)
2011-10-27 12:13 PDT, Boris Zbarsky [:bz] (still a bit busy)
christian: approval1.9.2.24+
Details | Diff | Splinter Review

Description Gervase Markham [:gerv] 2011-06-28 08:02:14 PDT
[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
Comment 1 Boris Zbarsky [:bz] (still a bit busy) 2011-06-28 08:11:24 PDT
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.
Comment 2 Gervase Markham [:gerv] 2011-06-28 08:22:20 PDT
The contact at Opera is Sigbjørn Vik <>. I don't know any more than what's in the email :-)

Comment 3 Boris Zbarsky [:bz] (still a bit busy) 2011-06-28 08:27:36 PDT
OK, I mailed him.
Comment 4 Boris Zbarsky [:bz] (still a bit busy) 2011-06-28 08:32:47 PDT
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?
Comment 5 Gervase Markham [:gerv] 2011-06-29 04:00:38 PDT
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. 

Comment 6 Boris Zbarsky [:bz] (still a bit busy) 2011-06-29 07:46:06 PDT
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?
Comment 7 Daniel Veditz [:dveditz] 2011-06-29 17:34:04 PDT
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.
Comment 8 Boris Zbarsky [:bz] (still a bit busy) 2011-06-29 22:11:07 PDT
Created attachment 543064 [details] [diff] [review]
This is what Opera seems to have done

Unfortunately, I can't seem to run a test server on port 80, so can't test the "default port" codepath...
Comment 9 Jason Duell [:jduell] (needinfo me) 2011-07-06 17:39:29 PDT
Comment on attachment 543064 [details] [diff] [review]
This is what Opera seems to have done

Review of attachment 543064 [details] [diff] [review]:
Comment 10 Patrick McManus [:mcmanus] 2011-07-07 06:53:05 PDT
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.
Comment 11 Boris Zbarsky [:bz] (still a bit busy) 2011-07-07 08:30:18 PDT
> 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.
Comment 12 Boris Zbarsky [:bz] (still a bit busy) 2011-07-07 12:47:27 PDT
Comment 13 Boris Zbarsky [:bz] (still a bit busy) 2011-07-08 07:56:24 PDT 

dveditz, is this something we want to backport to 3.6?
Comment 14 Daniel Veditz [:dveditz] 2011-10-19 16:21:51 PDT
Is there any reason not to take this on 3.6.x?
Comment 15 Boris Zbarsky [:bz] (still a bit busy) 2011-10-27 10:36:08 PDT
> 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 16 Boris Zbarsky [:bz] (still a bit busy) 2011-10-27 12:13:15 PDT
Created attachment 570047 [details] [diff] [review]
1.9.2 branch fix
Comment 17 Boris Zbarsky [:bz] (still a bit busy) 2011-10-27 12:13:59 PDT
Comment on attachment 570047 [details] [diff] [review]
1.9.2 branch fix

Requesting 1.9.2 approval.
Comment 18 christian 2011-10-27 12:28:01 PDT
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!
Comment 19 Boris Zbarsky [:bz] (still a bit busy) 2011-10-27 12:55:29 PDT
Comment 20 Al Billings [:abillings] 2011-10-31 14:49:40 PDT
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?
Comment 21 Boris Zbarsky [:bz] (still a bit busy) 2011-10-31 14:52:55 PDT
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...
Comment 22 Al Billings [:abillings] 2011-10-31 14:58:07 PDT
Thanks, Boris! ;-)

I'm calling this verified1.9.2 based on the script.
Comment 23 Daniel Veditz [:dveditz] 2011-11-07 15:35:05 PST
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.
Comment 24 Huzaifa Sidhpurwala 2011-11-07 20:31:59 PST
Any plans to assign CVE to this?
Comment 25 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2011-12-07 14:29:16 PST
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.


Note You need to log in before you can comment on or make changes to this bug.