1148357 - CORS preflight bypass with Alt-Svc

Status: RESOLVED WORKSFORME

(Core :: Networking: HTTP, defect)

Description

[Muneaki Nishimura]

User Agent: Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2342.2 Safari/537.36

Steps to reproduce:

(1) Launch http://mallory.csrf.jp/altsvccors/
(2) Push 'Send XHR' button. Then, XHR with DELETE method is invoked and a non-simple CORS request is sent to http://csrf.jp/altsvc/corsendpoint.php.
(3) As a response of preflight, the server returns following two headers.
Alt-Svc: h2="alice.csrf.jp:8020"
Aceess-Control-Max-Age: 50000
(4) Push 'Send XHR' button 4 or more times. Then, XHR is sent to https://alice.csrf.jp:8020/altsvccors/ without preflight.
(5) You can see HTTP request data sent to alice.csrf.jp:8020 from following URL and you may find requests having DELETE method.
https://alice.csrf.jp:8020/altsvc/log.txt


Actual results:

mallory.csrf.jp can send non-simple CORS requests to https://alice.csrf.jp:8020 that doesn't support to handle preflight request.



Expected results:

Firefox should flush cache of preflight response when connecting to alternative services specified by Alt-Svc.

Comment 1

[Muneaki Nishimura]

Attachment: Sequence diagram of the attack flow

I made a sequence diagram to explain the attack scenario.

Comment 2

[Daniel Veditz [:dveditz]]

Anne: what should CORS requests do with an Alt-Svc response?

Comment 3

[Anne (:annevk)]

I'm surprised this is the first vulnerability with Alt-Svc. From reading the draft it seems very powerful. Are we the only one exposed to this because nobody else is doing OE?

What I think needs to happen is that if we trust an origin due to a CORS preflight, we should not trust that origin's alternatives. They need to opt in with preflight as well.

Comment 4

[Patrick McManus [:mcmanus]]

I'm not actually 100% convinced this one is a bug yet at least as presented. Read on:

step 1 is origin http://mallory.csrf.jp wants to send a cross origin DELETE to http://csrf.jp/ .. it needs a CORS Preflight to do so

step 2 - the preflight options is send to origin http://csrf.jp and routed to csrf.jp port 80 specifying origin http://mallory.csrf.jp. It receives the appropriate Access-Control-Allow stuff and an Alt-Svc directive of alice.csrf.jp:8020

step 3 the DELETE to host http://csrf.jp happens as expected via route csrf.jp port 80 because the alt-svc is still being validated

step 4 - the route of alice.csrf.jp:8020 for origin http://csrf.jp is validated only because alice presents a cert that authenticates for csrf.jp (comment 0 doesn't mention this but its an important required detail). csrf.jp can't set up any old server on the internet as an alternate of itself (that would be bad), they need to have a cert that matches csrf.jp

step 5 - click the button again and you see another DELETE to http://csrf.jp this time routed over h2 to host alice.csrf.jp on port 8020 without an additional preflight. This is not a DELETE to http://alice.csrf.jp, it is a DELETE to http://csrf.jp routed via alice. (and the various host, uri, and sni headers are consistent with the origin). From a web origin perspective at least this seems right - we just validated this operation with http://csrf.jp, there is no reason to do it again - the set of alternative services are meant to be semantically identical alternatives.

I understand its a little surprising but the PKI requirement is meant to knot the list of alternative services into a trustable set.

Comment 5

[Patrick McManus [:mcmanus]]

(In reply to Anne (:annevk) from comment #3)
> Are we the only one exposed to this because
> nobody else is doing OE?

No - this is about alt-svc generally, not OE in specific. Google is doing Alt-Svc (in progress afaik) and MSFT is expected to do it too based on side conversations. This, and 1148328, are not dependent specifically on OE. (as OE is a superset of Alt-Svc, I'm sure you could trigger them in that scenario - but as we see here its not necessary).

> 
> What I think needs to happen is that if we trust an origin due to a CORS
> preflight, we should not trust that origin's alternatives. They need to opt
> in with preflight as well.

I might be out of date, but we don't do that with DNS load balancing (or rebinding attacks) right? Alt-Svc seems like a much stronger version of load balancing because it is dynamic and the set is provably under the same control. Alt-Svc might actually be a mechanism we could use to phase out things we know are subject to rebinding.

Comment 6

[Muneaki Nishimura]

I think following scenario may be valid. The appspot.com shares same SAN certificate among users of their service.
https://www.ssllabs.com/ssltest/analyze.html?d=apprtc.appspot.com&hideResults=on&latest

If appspot starts to support h2 on the different port, an attacker who has an appspot subdomain can make anyone to send unpermitted CORS request to other site on appspot.

Comment 7

[Anne (:annevk)]

> I might be out of date, but we don't do that with DNS load balancing (or rebinding attacks) right?

I'm not sure. Jonas would know.

The certificate helps, but not for cases such as appspot.com. Perhaps appspot.com should ban Alt-Svc, but it seems hard to do that retroactively.

Comment 8

[Muneaki Nishimura]

(In reply to Anne (:annevk) from comment #3)
> What I think needs to happen is that if we trust an origin due to a CORS
> preflight, we should not trust that origin's alternatives. They need to opt
> in with preflight as well.

Not only CORS but also other kinds of origin based restriction are affected such as window.postMessage, CSP, Canvas's origin-clean feature.

Also, other than appspot.com, MSFT uses one wildcard certificate *.azurewebsites.net for any subdomains owned by azure users.
https://www.ssllabs.com/ssltest/analyze.html?d=azurespeedtest.azurewebsites.net&hideResults=on&latest

The Section 10 of Alt-Svc spec describes it's origin is Alternate-Protocol in SPDY. 
http://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-06#section-10

But the spec of Alternate-Protocol below allowed to change only the port number. 
https://www.chromium.org/spdy/spdy-protocol/spdy-protocol-draft2#TOC-Server-Advertisement-of-SPDY-through-the-HTTP-Alternate-Protocol-header

IMO, same restriction as Alternate-Protocol may keep balance though DNS level load balancing may not be possibile.

Comment 9

[Anne (:annevk)]

Yeah, while the certificate constraint is nice, you really need to constrain the certificate and have some kind of explicit opt-in that you are okay with sharing everything.

Comment 10

[Patrick McManus [:mcmanus]]

Thanks for all the comments.

We should probably consider if this can be a public discussion.

I think the concern here is based on a over-expectation of what CORS preflight is meant to do. imo its an origin level technology as most things in the web policy model are and should be and it doesn't address host level issues. To my eyes, cors preflight says roughly "code loaded from origin a wants to send you a particular kind of request to you, origin b - is that cool?" and if origin b replies ok, then code from origin a gets a lease to interact with b in the described way within the UA that made the preflight query.

This is not a host based policy. That lease isn't dependent on the address of b, or the address of a or of the client, for that matter. Nor does it matter if proxies are involved and the addresses are unknown. And it doesn't matter if any of those addresses change during the lease due to L4 load balancers, NATs, DHCP leases, DNS loadbalancing, geo DNS with mobile, or even multipath (all of which can happen). And this makes sense to me inside an origin model.

Which means the host at origin b can rely on the fact that, if this is a browser, a preflight has been done for the incoming transaction (if it requires one, of course) but it cannot rely on the fact that it is the same host. If that's important to the resource, it needs to check at time of use too. That's all current practice, and seems consistent with the web origin model.

WRT Alt-Svc, this is really a subset of the above techniques - further constricted by both the PKI and a requirement that the alt-svc is running something > h1 (eliminating the concern about cross protocol smuggling that cors helps with, but can be bypassed by rebinding anyhow). The origin is kept consistent, just as with DNS, so checking at time of use works fine.

To me, if two unrelated origins share a certificate it seems they've got much larger trust issues than needing to do a time-of-use check they already need to be doing.

Comment 11

[Anne (:annevk)]

It's very common for unrelated origins to share certificates. E.g. whatwg.org is setup that way. There's no expectation however that because whatwg.org origins share a certificate, one of the origins can mount an attack on the other.

The fact that Alt-Svc attaches meaning to the sharing of certificates where previously there was none is the problem. Using an Alt-Svc header to mount an attack is also a lot easier than attacking DNS or some such which you probably do not control.

Comment 12

[Patrick McManus [:mcmanus]]

an attacker does trivially control the DNS in a rebinding attack - it doesn't need some kind of spoofing or poisoning.. just setup 2 DNS A records for origin B (and you legitimately own B, so this is normal ops) with TTL of 1. B1 is the IP of the host that will approve the preflight (attacker control), B2 is the IP of any host that you want to 'attack' (receive xhr).

That's the immediate reason why every host needs to check at time of use - including the whatwg ones :) The preflight doesn't provide real protection.

In reply to Anne (:annevk) from comment #11)
> It's very common for unrelated origins to share certificates. E.g.
> whatwg.org is setup that way. There's no expectation however that because
> whatwg.org origins share a certificate, one of the origins can mount an
> attack on the other.

I think that's a mistake in their threat model - completely independent of 
Alt-Svc. Sharing the cert between B1 and B2 extended the trust.

The exact same DNS rebinding attack works there in an https context because of the shared cert - B1 approves the preflight and B2 handshakes ok for the for xhr because it has a cert that validates for origin B and it accepts the origin B hostname in the SNI. It will then receive the XHR so it needs to check at time of use. (it may reject B based on SNI, which I would argue is just a better time of use check.)

That exposure is independent of Alt-Svc.

Alt-Svc improves the situation by changing "IP of any host" to "a host that shares a cert with you, answers to the origin's SNI, and speaks > h1"

Comment 13

[Anne (:annevk)]

Why do you assume DNS control? That's not normal in a shared hosting setup.

Comment 14

[Patrick McManus [:mcmanus]]

fwiw I'm not actually vigorously opposed to adding more preflight checks with alternative services - we could easily make such a thing part of alt-svc validation rather than part of cors and validation is slow and async anyhow. That way it would apply to broader contexts than just cors. I just don't see that it really accomplishes anything more with the threat model than the PKI constraint currently does.

(In reply to Anne (:annevk) from comment #13)
> Why do you assume DNS control? That's not normal in a shared hosting setup.

That is interesting - it seems reasonable enough that if you're delegating operation of a hostname you're delegating the dns for it too but I spose you sometimes need to attack it instead of having it handed to you (I trust you with my cert but not my DNS is an odd relationship). That doesn't really change the security properties though its an interesting point.

At the end of the day if you share your cert with someone else you trust that they will not impersonate you in ways you don't like. Sharing certs among people you don't trust seems like something that can be improved.

as far as I can understand, specifically, it seems an attacker who
 1] operates content under the same cert
 2] cannot control your (unsecured) DNS
 3] cannot control your (unsecured) route
 4] but can publish arbitrary http headers

can now bypass the cors preflight from the host attackee's perspective.

but you aren't bypassing things like the Allow-Cookies bit or anything like that. The origin must still opt into them. The only thing that is changed is that a 3rd party server that has a trust relationship of some sort with the attacker can receive data that it did not expect, but is well labeled, easily dropped, and even contains an audit trail (in the form of the authority) to identify which of its trusted partners was doing something unexpected.

So I don't think the attack surface is actually increased because 2 and 3 are unsafe assumptions, and the mitigation for the old attack and the new attack is the same - time of use check of authority. When you get a transaction for a different origin you need to reject it just like you always have.

What is the meaningful increased exposure?

Comment 15

[Anne (:annevk)]

It's not odd. E.g. the certificate of github.io is also valid for github.com (github.com does appear to use another...). Now GitHub does not allow custom headers (yet), certainly would not allow DNS control, but are under the impression that sharing a certificate does not affect their security model.

I find it hard to reason about what additional exposure there is. Since cookies and HTTP authentication are not applicable here (since the origin is masked) the attack surface would be the classic firewall attack and anything with IP-based authentication.

So e.g. someuser.company.userland could attack intranet.company.com if they are sharing a certificate.

Comment 16

[Anne (:annevk)]

Adding explicit opt-in (aside from the certificate, which we should keep) for Alt-Svc seems like the simplest solution.

Comment 17

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

We do not revalidate cached preflights if a DNS binding changes as far as I know.

Comment 18

[Daniel Veditz [:dveditz]]

(In reply to Anne (:annevk) from comment #11)
> It's very common for unrelated origins to share certificates. E.g.
> whatwg.org is setup that way. There's no expectation however that because
> whatwg.org origins share a certificate, one of the origins can mount an
> attack on the other.

Extremely common with CDNs. The certificate currently given for https://www.cnn.com/ is good for

a.ssl.fastly.net, *.a.ssl.fastly.net, fast.wistia.com, purge.fastly.net, mirrors.fastly.net, *.parsecdn.com, *.fastssl.net, voxer.com, www.voxer.com, *.firebase.com, sites.yammer.com, sites.staging.yammer.com, *.skimlinks.com, *.skimresources.com, cdn.thinglink.me, *.fitbit.com, *.hosts.fastly.net, control.fastly.net, *.wikia-inc.com, *.perfectaudience.com, *.wikia.com, f.cloud.github.com, *.digitalscirocco.net, *.etsy.com, *.etsystatic.com, *.addthis.com, *.addthiscdn.com, fast.wistia.net, raw.github.com, www.userfox.com, *.assets-yammer.com, *.staging.assets-yammer.com, assets.huggies-cdn.net, api.kinja.com, orbit.shazamid.com, about.jstor.org, *.global.ssl.fastly.net, web.voxer.com, pypi.python.org, *.12wbt.com, www.holderdeord.no, secured.indn.infolinks.com, play.vidyard.com, play-staging.vidyard.com, secure.img.wfrcdn.com, secure.img.josscdn.com, *.gocardless.com, widgets.pinterest.com, *.7digital.com, *.7static.com, p.datadoghq.com, *.plan3.se, new.mulberry.com, www.safariflow.com, cdn.contentful.com, tools.fastly.net, *.huevosbuenos.com, *.goodeggs.com, *.fastly.picmonkey.com, *.cdn.whipplehill.net, *.whipplehill.net, cdn.media34.whipplehill.net, cdn.media56.whipplehill.net, cdn.media78.whipplehill.net, cdn.media910.whipplehill.net, *.modcloth.com, *.disquscdn.com, *.jstor.org, *.dreamhost.com, www.flinto.com, *.chartbeat.com, *.hipmunk.com, content.beaverbrooks.co.uk, secure.common.csnstores.com, *.vsco.co, www.joinos.com, staging-mobile-collector.newrelic.com, *.modcloth.net, *.foursquare.com, *.shazam.com, *.4sqi.net, *.metacpan.org, *.fastly.com, wikia.com, fastly.com, kinja.com, *.gadventures.com, www.gadventures.com.au, www.gadventures.co.uk, kredo.com, cdn-tags.brainient.com, my.billspringapp.com, rvm.io

Those origins have nothing to do with each other.

Comment 19

[Patrick McManus [:mcmanus]]

> Those origins have nothing to do with each other.

They share operations - and that's a big deal. They share a cert and their operators can MITM each other trivially. I'd say that's a lot to do with each other in practical terms.

I understand the argument here is that the person that controls the headers isn't necessarily the person that controls the domain operations - but let's say that and not that they have nothing to with each other. At the operational level they already trust each other completely.

This also means they can impersonate each other for the purposes of any additonal cors checks we do. Doing an additional check might make things harder for one particular common configuration, but I don't think it adds anything you can rely on to the security model and eventually it will just be cruft.. sort of like historical practice of restricting low numbered ports to administrators.

in the bigger picture, I think its good to move to a model where origins are identified cryptographically rather than via DNS/TCP/IP.

(fwiw when I fetch that cnn cert it is ssl_bad_cert_domain and thus it would be rejected by the altsvc algorithm when doing cors. I don't doubt that you can find a legit one with long list of SANs though.)

Comment 20

[Daniel Veditz [:dveditz]]

Yeah, CNN is not on that list and doesn't seem to support TLS. I'm just saying where I found the cert because sometimes if you go to individual names on that list using Firefox which supports SNI you'll get just a simple cert for the domain instead of the giant cert set up for old browsers that don't support SNI.

Comment 21

[Anne (:annevk)]

It still seems the easiest solution here is to amend Alt-Svc to require a designated server to opt in through some kind of Alt-Svc response header of its own.

Comment 22

[Muneaki Nishimura]

I think this is very similar threat to DNS rebinding attack. In this scenario, HTTP/2 requests sent from Firefox to an alternative server (alice.csrf.jp) contains the origin's hostname (mallory.csrf.jp) in :authority field of HEADERS frame.

As Daniel said in the last comment of Bug 1106687, the protection against DNS rebinding attack should usually be taken in server side by verifying Host field in HTTP/1.1 case. I think this scenario can take same way, i.e., checking if the :authority field is expected origin in each server.

The protection idea that Anne says may work fine, however, timing to indicate "opt-in" by an alternative-server needs to be discussed because in this scenario, the first request from Firefox to the alternative is an unexpected DELETE request in HTTP protocol level. If the alternative want to avoid the DELETE request, "opt-in" has to be taken before starting HTTP communication, e.g., during TLS handshake. However, I'm not sure it is appropriate design in a manner of TLS.

Comment 23

[Daniel Veditz [:dveditz]]

(In reply to Patrick McManus [:mcmanus] from comment #12)
> In reply to Anne (:annevk) from comment #11)
> > It's very common for unrelated origins to share certificates. E.g.
> > whatwg.org is setup that way. There's no expectation however that because
> > whatwg.org origins share a certificate, one of the origins can mount an
> > attack on the other.
> 
> I think that's a mistake in their threat model - completely independent of 
> Alt-Svc. Sharing the cert between B1 and B2 extended the trust.

This appears to be a security model mismatch (I won't say "bug") in the Alt-Svc protocol, only specific to Gecko because we got there first. The IETF and W3C folks need to hash out their differences. Any objections to unhiding this bug so it can be discussed in the appropriate technical groups?

Comment 24

[Patrick McManus [:mcmanus]]

I'm fine with opening this. I believe things very similar have been discussed in public in the past.

Comment 25

[Muneaki Nishimura]

I think the current implementation of Alt-Svc in Gecko is not affected by this bug because OE is restricted to use only when an alternative host specified by an Alt-Svc header is same origin as the original host.
This change was due to bug 1153212 and was introduced by the following commit.
http://hg.mozilla.org/mozilla-central/diff/2124a617b3bc/netwerk/protocol/http/nsHttpConnectionMgr.cpp#l1.228

If this limitation came from any official specification related to OE this bug may not be a specification issue and it should be closed as invalid.
However if this limitation is not clearly mentioned at the moment, I think it should be reflected to a official specification.

Comment 26

[Muneaki Nishimura]

It seems that the public discussion regarding this issue has been started on the IFTF HTTP-WG mailing list.
https://lists.w3.org/Archives/Public/ietf-http-wg/2015AprJun/0545.html

I think other CORS like mechanism should also be taken into account on the discussion.
In the case of the crossdomain.xml on the Flash, time of load the xml and time of send a cross origin request is very distant unlike CORS.

Comment 27

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

Dan, is there something for us to do here? This has been sitting around for a while and we were talking about opening up this bug.

Comment 28

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

Muneaki,

Since this is a spec issue right now, we are minusing for bounty. If this gets resolved and there is a code issue for Mozilla to address, please email [e-mail] and let us know.

Comment 29

[Andrew McCreight [:mccr8]]

Per comment 25, it sounds like Firefox is not affected by this, but somebody should file a spec issue elsewhere.