1749129 - Side-channel attack can deanonymize users (potential risk to journalists and activists)

Status: NEW

(Core :: DOM: Core & HTML, defect, P5)

Description

[Yossi Oren]

Attachment: paper_main.pdf

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.2 Safari/605.1.15

Steps to reproduce:

Dear Mozilla,

My co-authors and I are security researchers from the New Jersey Institute of Technology. On 1/Feb, we plan to submit a paper to the USENIX Security Symposium, titled "Targeted Deanonymization via the Cache Side Channel: Attacks and Defenses".

In this paper, we describe a side-channel attack technique which lets a malicious website discover whether a visitor to the website bears a certain public identifier, such as an email address or a Twitter handle. Our attack works against multiple operating systems, including Windows, MacOS and Android. It affects multiple browsers, including Tor, Safari and Chrome. It can target major sites including Google, Twitter, LinkedIn, TikTok, Facebook, Instagram and Reddit.

We also present a full-featured defense against the attack, deployed as a browser extension. The paper includes an artifact repository containing a proof-of-concept attack, which can be accessed here:

https://github.com/leakuidatorplusteam/artifacts

We attach a draft of the paper, including some guidance for browser vendors, website creators and users. We would be happy to discuss our findings with you, and are looking forward to collaborating with you in responsibly addressing the risks we identified. For your information, the embargo request date for the USENIX Security Symposium is Tuesday, July 12, 2022, and the paper will be released to the public on Wednesday, August 10, 2022, as listed here:

https://www.usenix.org/sites/default/files/sec22_cfp_092821.pdf

Please note that the paper draft we are sharing is not public at this point in time. As such, we ask that you do not distribute it outside your organization.

Respectfully yours,
-Reza, Yossi, and Mojtaba

Comment 1

[Yossi Oren]

Cross reference with Chromium bug:

https://bugs.chromium.org/p/chromium/issues/detail?id=1285604

Comment 2

[Yossi Oren]

Can you please cc [e-mail] ?

Comment 3

[Yossi Oren]

Hi Anne, I asked to add you because of your important work on Cross-Origin-Opener-Policy.

Comment 4

[Yossi Oren]

To access the PoC repo:

git clone https://read_only_user:[e-mail]/leakuidatorplusteam/artifacts.git
(Token expires on Sun, Apr 10 2022)

Comment 5

[Anne (:annevk)]

Thank you Yossi! Given Total Cookie Protection and state/storage partitioning the main attack vector we have to worry about is new windows I think, which is what section 6.3.2 states as well. It seems to me this is a PoC of what has been discussed in XSLeaks meetings as well, namely using the CPU caches as a global side channel. Essentially any global resource can be (ab)used as such.

I'm a bit puzzled by the CORB suggestion in 6.3.3. It seems that would essentially come down to disabling cross-origin new windows altogether?

(The fact that we have gotten to the point whereby we force attackers to open new windows does suggest that software-imposed boundaries have helped, I think. But I'll readily concede that opening a new window is trivial.)

Comment 6

[Yossi Oren]

Hi, we saw mention of the attacks based on the browser's response cache in the XSLeaks wiki, but no mention of the CPU cache:

https://xsleaks.dev/docs/attacks/cache-probing/

If this idea was already suggested by somebody from your side, we would be happy to give credit where it's due.

As for the CORB suggestion, I don't suggest cross-origin new windows should be disabled, but perhaps they should be subject to the exact same limitations and policies you would apply to cross-origin iframes (in particular putting their cookies in a special cookie jar).

One interesting thing that you mentioned are "XS-Leaks meetings". Is this a periodic event? If so, will you consider having a guest speaker? My student Mojtaba would be happy to present our work in such a meeting.

Comment 7

[:Gijs (he/him)]

Tentatively moving to Core :: DOM, as any restrictions for cross-origin window opening would need to be implemented there.

Comment 8

[Anne (:annevk)]

Tom Van Goethem and I have discussed these kind of resource contention attacks, but I'm not sure there is something specific to cite. What is particularly interesting here though is that with the CPU cache you can go way beyond 1 bit of information.

As for mitigations:

1. We could indeed apply partitioning of some kind to cross-origin windows, but conveying this information to the user might not be possible. ("Refresh this page to make it work" isn't going to fly with the UX team.)
2. We could have an interstitial similar to certain TLS failures. This would make attacks harder I think, but it would also make navigating around the web harder.
3. ?

(I emailed about XSLeaks.)

Comment 9

[Yossi Oren]

Hi, some update from Mojtaba, who was trying out iframe-based attack method for various settings of Enhanced Tracking Protection.

So, when ETP was set to "Standard", we were able to deanonymize YouTube users even if the attack page was in the same iframe (accuracy 99±3%).
When ETP was set to "Strict", on Firefox Windows, the iframe-based attack was not successful (accuracy of around 50% - basically a random guess).
However, when ETP was set to "Strict", on Firefox Mac the iframe-based attack was surprisingly still successful (accuracy 98±2%). This is Firefox 96 on macOS Catalina 10.15.7, running on an Intel MacBook Pro.

Mojtaba noticed that the video wasn't loading properly, because DoubleClick cookies were being blocked, but YouTube cookies were still coming through. Is this a bug in the Mac version?

+Mojtaba, if there are any technical questions feel free to answer...

Comment 10

[Anne (:annevk)]

Tim, could you take a look at comment 9? Perhaps that's because YouTube calls requestStorageAccess() and it goes through without prompt?

Comment 11

[Tim Huang[:timhuang]]

Sure, I can look into that. But the Poc link doesn't work for me; it's a 404 page when I opened it. Maybe I need Github permission so that I can access it?

And Yossi, would you be able to help with verifying if Youtube acquired storage access under your Poc site. You can check this by the Site Permissions Panel. Could you check if there is a Cross-site cookies permission for Youtube over there? Thanks.

Comment 12

[Yossi Oren]

Hi Tim, you need to use the following command line to download the repo:

git clone https://read_only_user:[e-mail]/leakuidatorplusteam/artifacts.git

I'll let Mojtaba handle the technical questions...

Comment 13

[Mojtaba Zaheri]

Hi Tim, yes there is a Cross-site cookies permission for YouTube in the Site Permissions Panel.
This permission is granted to the website automatically in a prior interaction, when opening YouTube in a popup window through user click. It happened for Twitter as well, through similar interactions.

Comment 14

[Tim Huang[:timhuang]]

(In reply to Mojtaba Zaheri from comment #13)

Hi Tim, yes there is a Cross-site cookies permission for YouTube in the Site Permissions Panel.
This permission is granted to the website automatically in a prior interaction, when opening YouTube in a popup window through user click. It happened for Twitter as well, through similar interactions.

Comment 13 explains why the Poc works with Total Cookie Protection enabled. The storage access was granted because of the heuristics that Firefox will grant the storage access if Firefox detects that it's a login scenario. You can try to disable the heuristics by flipping off the pref privacy.antitracking.enableWebcompat and check if the Poc still works.

Comment 15

[Mojtaba Zaheri]

(In reply to Tim Huang[:timhuang] from comment #14)

Comment 13 explains why the Poc works with Total Cookie Protection enabled. The storage access was granted because of the heuristics that Firefox will grant the storage access if Firefox detects that it's a login scenario. You can try to disable the heuristics by flipping off the pref privacy.antitracking.enableWebcompat and check if the Poc still works.

I tested and confirm that after flipping off the privacy.antitracking.enableWebcompat pref, opening YouTube in a popup doesn't grant access, and the iframe-based attack in the PoC is mitigated with Total Cookie Protection enabled in ETP Strict Mode.

Comment 16

[Mojtaba Zaheri]

Comments #13, #14 and #15 show that the web compatibility heuristics, enabled by default, provide avenues for attackers to bypass the protection against the same-window cross-site leaks in ETP Strict Mode, which is more than what is available through a cross-window reference. For example, consider the following scenario:

1. The user clicks somewhere inside the attacker webpage
2. The attacker opens youtube.com in a popup
3. youtube.com permission is auto granted for the attacker webpage
4. The attacker webpage looks for youtube.com cross-site leaks in the same window of the attacker webpage; our iframe-based attack is one of the possible XS-leaks that now becomes possible. Step 4) can be repeated multiple times in the future, the attacker’s webpage has now been granted youtube.com permissions.

This example shows how a user that browses in ETP Strict Mode may end up being exposed to iframe-based XS-leaks, our iframe-based attack being one of them.

Have you considered turning off by default the privacy.antitracking.enableWebcompat preference in ETP Strict Mode? That would avoid the above scenario.

Comment 17

[Mojtaba Zaheri]

I was wondering if there are any thoughts on the question in comment 16?

Also, have there been any developments overall on this issue?

Comment 19

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

Thanks for the report.

As part of our privacy work, we're aiming to increasingly limit (and eventually eliminate) the Web Compat heuristics discussed above, which should help protect against this attack.

Broadly speaking, we think this work is very interesting, but aren't yet convinced that it's practical enough to warrant significant investments in mitigations at the expense of other privacy and security workstreams. We look forward to reading about further developments.

Comment 20

[Mojtaba Zaheri]

A moderate alternative to prior suggestions is to extend the fetch metadata HTTP request headers with more information about the context from which the request originated. As a result, website owners can better decide on how to respond to a potentially suspicious request.

Two suggested information that can be added to fetch metadata headers include;

1. Whether the request is made from a popup/popunder or not, and
2. Whether there exists an opener/child relationship between the window or tab the request originates from and another window or tab currently open in the browser, with a differing site on address bar

Consequently, the server will have more information about the context in which the request is made and can tailor their endpoints’ responses based on this extra information. For example, when a request is made in a popup/popunder or there exists an opener/child relation with a differing site, websites can decide to prompt user action before navigating to a webpage rendering a leaky resource (video, audio, image, post, etc.) while not prompting user action before rendering a webpage for a third party authentication endpoint.

In our preliminary discussions with service providers (such as Twitter) on potential mitigations, it was clear that a joint effort involving the browser vendor and the service provider may be the most practical and realistic way to devise mitigations. The suggestions above follow this approach.

Comment 21

[Anne (:annevk)]

Mojtaba, I discovered I proposed something similar in 2019: https://github.com/w3c/webappsec-fetch-metadata/issues/17. I still like the idea as it complements Cross-Origin-Opener-Policy in the same way some of the other Sec-Fetch-* fields complement Cross-Origin-Resource-Policy. It seems worth revisiting and I'd encourage you to open a new issue against that repository to start that discussion.

Comment 22

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Change to S3/P5 according to previous comments.

Comment 23

[Mojtaba Zaheri]

Anne, it is interesting to see a similar proposal made in 2019. Here is the link to the new issue for reference: https://github.com/w3c/webappsec-fetch-metadata/issues/83

Comment 24

[Reza Curtmola]

An update on this: Our paper describing targeted deanonymization attacks was accepted for publication in the 2022 USENIX Security Symposium (see initial post in this thread). The embargo request date for the USENIX Security Symposium is Tuesday, July 12, 2022, and the paper will be released to the public on Wednesday, August 10, 2022, as listed here:
https://www.usenix.org/sites/default/files/sec22_cfp_092821.pdf

Comment 25

[Reza Curtmola]

To make my previous comment a bit more clear: if any of the parties included on this bug thread would like us to embargo the paper until August 10, please let us know here. Thank you!

Comment 26

[John Wilander]

Hi! John Wilander from WebKit here. The bug reporter gave me access after we requested the ability to coordinate with Mozilla. We do not have an open source bug tracking this yet so I can't give you access to any such thing. Would you like to meet and discuss?

Comment 27

[Mojtaba Zaheri]

Here is an interesting news article about Web Request API:

https://www.theverge.com/2022/6/10/23131029/mozilla-ad-blocking-firefox-google-chrome-privacy-manifest-v3-web-request

It affects Leakuidator+ extension, a defense we proposed to mitigate targeted deanonymization attacks.

Comment 28

[:Gijs (he/him)]

(In reply to John Wilander from comment #26)

Hi! John Wilander from WebKit here. The bug reporter gave me access after we requested the ability to coordinate with Mozilla. We do not have an open source bug tracking this yet so I can't give you access to any such thing. Would you like to meet and discuss?

--> Tom?

Comment 29

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

Martin is coordinating

Comment 30

[Martin Thomson [:mt:]]

I met with John and we talked about options for addressing this. What came up as potentially useful:

1. Anne's suggestion about Sec-Fetch-* metadata (https://github.com/w3c/webappsec-fetch-metadata/issues/83). This might work in the mid-term with site cooperation.
2. More progress on treating nested and auxiliary browsing contexts as subservient to their parent from a storage access standpoint. We discussed applying stricter storage access policy constraints here, including interstitials before loading. These strategies are likely unworkable from the perspective of either breaking sites (no cookies) or being seriously annoying (interstitials). The storage access constraints might work longer term, but I don't see any way to implement these techniques otherwise.
3. For popunders (which are a blight) some work might be done to delay loading until the window receives focus.
4. (not discussed with Apple, but discussed with dveditz) it might be possible to implement a frame-ancestors -like CSP policy for window.open(). We'd want to be careful to avoid this being used for deep-linking (it couldn't block all navigation) but it might offer sites a more reliable way to prevent being invoked in popups.

The fundamental problem here is not that sites can instantiate child browsing contexts with privileges; that is just one relatively easy way to ensure that the attack can be mounted and the effects measured. The real problem is that loading pages creates signals that can be observed by other active pages. This work demonstrates it is possible to reliably distinguish gross differences in the patterns created by loading pages. Improvements in technique will likely only make it easier to distinguish with smaller differences.

If a site can load the target content and concurrently observe (from another browsing context), then it can also observe these signals. This is possible with navigation, frames, or window.open(). Top-level navigation works if the site has enough active windows or tabs and there we cannot rely on storage partitioning or any of the above mitigations.

The mitigation proposed in the paper is also unlikely to be feasible in general: the unprivileged load is unlikely to produce a functional user experience in a lot of the scenarios in which cookies are needed, such as federated login.

If we were to seriously consider doing something here, maybe we could freeze processing on the linking site while the linked site loads, perhaps based on which site has focus. That has some serious performance drawbacks, along with some nasty failure modes, but it might be effective for cases where privacy is more important. Of course, that too assumes that navigation is special enough to justify extra protection. The attack works any time a site is able to observe (and know that it is observing) processing on information it is not supposed to access.

However, I think that the general view of this attack is that while it is technically interesting and overall very concerning, there are probably more immediate problems to concentrate on for the moment. Doing the work on Sec-Fetch-? is worthwhile and we want to keep an eye out for further refinements in the technique, but the other mitigations on offer currently appear to be expensive, to narrowly targeted, disruptive, unlikely to stand long-term, or some combination of those.

Comment 31

[Yossi Oren]

Hi everybody, the bug has been idle for 11 months. In the meantime, the paper and presentation are available since last November, including PoC code:

https://www.usenix.org/conference/usenixsecurity22/presentation/zaheri

https://github.com/leakuidatorplusteam/artifacts

It was also covered by Wired:

https://www.wired.com/story/web-deanonymization-side-channel-attack-njit/

The corresponding Chromium bug was recently made public:
https://bugs.chromium.org/p/chromium/issues/detail?id=1285604

Would it be OK to make the Bugzilla report public as well? Thanks!

Comment 32

[Martin Thomson [:mt:]]

The cat has been out of the bag for some time. Dan, can you make the appropriate gestures to open this?