1553003 - Tracking and History Exfiltration with Alt-Svc on Firefox

Status: RESOLVED FIXED

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

Description

[Trishita Tiwari]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:66.0) Gecko/20100101 Firefox/66.0

Steps to reproduce:

Contributors: Trishita Tiwari (me) and Prof. Ari Trachtenberg (my advisor) from Boston University.

General Description:
The HTTP Alternative Services header (Alt-Svc) implementation on the Firefox browser may be abused by an attacker to compromise security measures, for instance, user tracking and history exfiltration. (Note that other attacks related to the Alt-Svc implementation on Firefox have been filed in separate reports, as indicated in the bugzilla guidelines)

To effect these compromises, an attacker need only have the victim visit a website under the attacker’s control (either as a first party or a third party through an image/iframe). The attacker’s website specifies an Alt-Svc header that enables the various attacks in a manner that is not visible to the victim (i.e. URL and domain name visible in the browser are not affected).

More details on tracking and history exfiltration:

By specifying a unique Alt-Svc for each user, and observing for subsequent user requests, an attacker could track a user both as a first party website and a third party iframe (or image). Such third party tracking bypasses the built-in third party tracker blockers available on Firefox.

Further, since the Alt-Svc permits specifying a unique domain and port combination, the victim’s ISP can track the use of a unique Alt-Svc values, instead of MAC addresses which are now sometimes randomized by hardware vendors.

To effect such network-layer Alt-Svc tracking, an ISP could embed a tracking iframe that specifies a unique Alt-Svc in the ISP's network login web page (e.g., Starbucks or McDonalds WiFi); this makes the victim cache a unique header for the tracking iframe. Next, to determine which unique alt-svc was assigned to a given user, the ISP (and this could be a different ISP than before) inserts the same tracking iframe into its login page and monitors which unique Alt-Svc endpoint the client loads; recall that target IP addresses and ports are not encrypted even when accessing an https site.  This technique improves upon unique third-party cookies in tracking iframes, which are often blocked.

Finally, using the Alt-Svc header, an ISP could exfiltrate a victim browser’s history. The ISP can deduce this information even if the victim’s prior visits to these websites were through a different (unobservable) ISP. The attack involves a technique similar to the ISP level tracking attack. Consider an ISP that wishes to know whether a particular user visited www.illegal.com sometime in the past.  For the sake of exposition, assume that www.illegal.com also sets an Alt-Svc header that points to its HTTP2 endpoint alt.illegal.com. Now all the ISP needs to be able to do is to insert an image or iframe from www.illegal.com into their login web page (or any other webpage that they control). Then the ISP needs to monitor where the image/iframe is loaded from--the original domain, or the Alt-Svc domain. If it is loaded from the Alt-Svc endpoint, then the user must have visited the website before; otherwise, the website was not visited.

Actual results:

Demo: We show how third party tracking is possible through Alt-Svc (even after the browser has been configured to block all third party trackers--you can check this by enabling third party tracking protection on your browser). In our setting, two different web pages wish to track a user. Both these web pages embed a tracking iframe from a common domain (this tracking domain is colluding with the two websites). This tracking iframe sets a unique Alt-Svc, and the user uses this Alt-Svc for every subsequent load of the iframe (regardless of what the first party domain is). The other attacks--first party tracking, ISP tracking, and ISP history exfiltration have a similar set up, and so we do not provide explicit demos for those attacks (unless requested).

Demo link:
For third party collusion tracking, visit http://zero.gotdns.ch:9000/h2/tracking-landing.html to install the Alt-Svc. Keep reloading the page until the text in the iframe says “Alternate Iframe”. Once this happens, the browser has cached the Alt-Svc for the tracking iframe.

Now visit http://one.ddnsking.com:9000/h2/tracking-landing.html, where you will see that the browser reuses the earlier cached Alt-Svc to load the iframe.

Expected results:

Mitigations:

1. Firefox should prevent a website from setting Alt-Svcs through third party content (such as images and iframes). This will make third party tracking harder, and will decrease the feasibility of history exfiltration attacks.
2. Additionally, like Tor, Firefox may want to consider first-party isolation for the Alt-Svc cache, which would also help prevent such attacks

Comment 1

[:Gijs (he/him)]

In bug 1552993 comment #22, the reporter noted they intend to present their findings in August. This got rated sec-moderate and is (AFAIK) unfixed. Just flagging this up - I'm not familiar enough with our tracking work to know what our options are here, though August is... unfortunate... given our release schedule, AFAICT.

Comment 2

[Steven Englehardt [:englehardt]]

Thanks for the report! The scenarios you describe look valid to me. I think it's much more likely that we'll see abuse by web resources than an ISP, so addressing that first seems like a priority.

Firefox should prevent a website from setting Alt-Svcs through third party content (such as images and iframes). This will make third party tracking harder, and will decrease the feasibility of history exfiltration attacks.

It seems like this will make the history exfiltration attacks much worse, since the user loses the ability to deny that they visited a site as a first party. Using your example: the user could claim that they never actually visited illegal.com, but that illegal.com set an Alt-Svc header while embedded as a third-party without the user's knowledge (perhaps by an ISP attempting to mount a history sniffing attack).

Firefox may want to consider first-party isolation for the Alt-Svc cache, which would also help prevent such attacks

This seems like the right approach to me. Reading through the spec [0] the cross-site tracking concern seems to be a known issue and double keying aligns with their recommended mitigation. We should address this by double keying the Alt-Svc cache for all domains. We also have the option of ignoring the header for domains classified as trackers (roughly aligning to how we treat cookies [1]). The benefit of taking the latter approach is that it prevents passive third-party content from establishing a same-site identifier for the user.

Ehsan, does that make sense to you?

[0] https://tools.ietf.org/html/rfc7838#section-9.4
[1] https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Privacy/Storage_access_policy#What_does_the_storage_access_policy_block

Comment 3

[Trishita Tiwari]

(In reply to Steven Englehardt [:englehardt] from comment #2)

Thanks for the report! The scenarios you describe look valid to me. I think it's much more likely that we'll see abuse by web resources than an ISP, so addressing that first seems like a priority.

Firefox should prevent a website from setting Alt-Svcs through third party content (such as images and iframes). This will make third party tracking harder, and will decrease the feasibility of history exfiltration attacks.

It seems like this will make the history exfiltration attacks much worse, since the user loses the ability to deny that they visited a site as a first party. Using your example: the user could claim that they never actually visited illegal.com, but that illegal.com set an Alt-Svc header while embedded as a third-party without the user's knowledge (perhaps by an ISP attempting to mount a history sniffing attack).
Ah yes, I see your point ... this makes sense

Firefox may want to consider first-party isolation for the Alt-Svc cache, which would also help prevent such attacks

This seems like the right approach to me. Reading through the spec [0] the cross-site tracking concern seems to be a known issue and double keying aligns with their recommended mitigation. We should address this by double keying the Alt-Svc cache for all domains. We also have the option of ignoring the header for domains classified as trackers (roughly aligning to how we treat cookies [1]). The benefit of taking the latter approach is that it prevents passive third-party content from establishing a same-site identifier for the user.

Ehsan, does that make sense to you?

[0] https://tools.ietf.org/html/rfc7838#section-9.4
[1] https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Privacy/Storage_access_policy#What_does_the_storage_access_policy_block

Comment 4

[(no longer active)]

(In reply to Steven Englehardt [:englehardt] from comment #2)

Thanks for the report! The scenarios you describe look valid to me. I think it's much more likely that we'll see abuse by web resources than an ISP, so addressing that first seems like a priority.

Yeah. It seems pretty similar in nature to the timing attacks on the HTTP cache (see bug 1536058 and https://github.com/whatwg/fetch/issues/904).

Firefox should prevent a website from setting Alt-Svcs through third party content (such as images and iframes). This will make third party tracking harder, and will decrease the feasibility of history exfiltration attacks.

It seems like this will make the history exfiltration attacks much worse, since the user loses the ability to deny that they visited a site as a first party. Using your example: the user could claim that they never actually visited illegal.com, but that illegal.com set an Alt-Svc header while embedded as a third-party without the user's knowledge (perhaps by an ISP attempting to mount a history sniffing attack).

Indeed. It's similar to suggesting to solve the cache timing attack by disabling writes to the cache from third-party contexts.

Firefox may want to consider first-party isolation for the Alt-Svc cache, which would also help prevent such attacks

This seems like the right approach to me. Reading through the spec [0] the cross-site tracking concern seems to be a known issue and double keying aligns with their recommended mitigation. We should address this by double keying the Alt-Svc cache for all domains. We also have the option of ignoring the header for domains classified as trackers (roughly aligning to how we treat cookies [1]). The benefit of taking the latter approach is that it prevents passive third-party content from establishing a same-site identifier for the user.

Ehsan, does that make sense to you?

Yes, it does.

With the refactoring done in bug 1535697, fixing this bug is actually quite easy (the coding part of it at least):

• Pass GetTopWindowOrigin() down into GetAltServiceMapping().
• Pipe that argument all the way down to AltSvcMapping::MakeHashKey().
• AltSvcMapping::mTopWindowOrigin already exists and is being serialized/deserialized, so in theory only modifying the way we generate the hash key above should be sufficient to fix this bug.

Separately to the general protection, I think it makes sense to treat third-party trackers which are isolated by ETP especially here as well, similar to what we did for HTTP cache for example. For that, I filed bug 1569224.

Comment 5

[Anne (:annevk)]

Created https://github.com/whatwg/fetch/security/advisories/GHSA-4rg4-5cqh-842x to track this standards-wise and for coordination with other browsers. (I'd expect this partitioning to end up in Fetch eventually.)

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:mayhemer, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 7

[Anne (:annevk)]

Dragana, Tim, I think this is fixed now, right? In light of bug 1673921?

That is, from OP we have implemented the same mitigation Tor has, and even further tightened that scope to also include the scheme.

I don't think we do 1 as suggested there, but that does not seem to be needed if we do 2. OP, please correct me if I'm wrong.

Comment 8

[Tim Huang[:timhuang]]

(In reply to Anne (:annevk) from comment #7)

Dragana, Tim, I think this is fixed now, right? In light of bug 1673921?

That is, from OP we have implemented the same mitigation Tor has, and even further tightened that scope to also include the scheme.

Yes, the Alt-Svc has been keyed by the OAs in Bug 1334690 and the partitionKey has been set properly in OAs to partition the Alt-Svc.

I don't think we do 1 as suggested there, but that does not seem to be needed if we do 2. OP, please correct me if I'm wrong.

I agree that we don't need 1 if we have implemented 2 because the Alt-Svc has been partitioned across different first parties. So, it won't be possible to track users by using this.

Thus, I think we can close this bug. But, I'd like to see Dragana's opinion before closing this.

Comment 9

[Dragana Damjanovic [:dragana]]

The bug fixes this issue.