667907 - (CVE-2011-3656) Possible XSS via HTTP 0.9 errors and content-sniffing

Status: RESOLVED FIXED

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

Description

[Gervase Markham [:gerv]]

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

Hi

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.

http://www.opera.com/docs/changelogs/windows/1150/: "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
[e-mail]
https://list.opera.com/mailman/listinfo/mb-secissues

Comment 1

[Boris Zbarsky [:bzbarsky]]

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]]

The contact at Opera is Sigbjørn Vik <[e-mail]>. I don't know any more than what's in the email :-)

Gerv

Comment 3

[Boris Zbarsky [:bzbarsky]]

OK, I mailed him.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Specifically what I sent:

Sigbjørn,

This mail is about your post to MB-Secissues about HTTP 0.9 and sniffing.  There's a Gecko bug tracking this at https://bugzilla.mozilla.org/show_bug.cgi?id=667907 (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]]

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. 

Gerv

Comment 6

[Boris Zbarsky [:bzbarsky]]

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
    them." 
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]]

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 [:bzbarsky]]

Attachment: 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]

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]]

the content type of a http/0.9 is supposed to be html, not plain. 

http://www.w3.org/Protocols/HTTP/AsImplemented.html

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 [:bzbarsky]]

> 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 [:bzbarsky]]

http://hg.mozilla.org/integration/mozilla-inbound/rev/46e2febf2841

Comment 13

[Boris Zbarsky [:bzbarsky]]

http://hg.mozilla.org/mozilla-central/rev/46e2febf2841 

dveditz, is this something we want to backport to 3.6?

Comment 14

[Daniel Veditz [:dveditz]]

Is there any reason not to take this on 3.6.x?

Comment 15

[Boris Zbarsky [:bzbarsky]]

> 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 [:bzbarsky]]

Attachment: 1.9.2 branch fix

Comment 17

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 570047 [details] [diff] [review]
1.9.2 branch fix

Requesting 1.9.2 approval.

Comment 18

[LegNeato]

Comment on attachment 570047 [details] [diff] [review]
1.9.2 branch fix

Approved for 1.9.2.24. Please land on releases/mozilla-1.9.2 default branch asap. Thanks!

Comment 19

[Boris Zbarsky [:bzbarsky]]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/6a2e0eefeb5f

Comment 20

[Al Billings [:abillings - ex-MoCo]]

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 [:bzbarsky]]

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 - ex-MoCo]]

Thanks, Boris! ;-)

I'm calling this verified1.9.2 based on the script.

Comment 23

[Daniel Veditz [:dveditz]]

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]

Any plans to assign CVE to this?

Comment 25

[u279076]

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.

Thanks