Extending the fetch metadata headers: related tabs/windows

[mjz3]

In a recent security disclosure [1, 2], we show how targeted deanonymization attacks performed via the CPU cache side channel can circumvent browser-based defenses. The attack framework we show is able to overcome the limitations of prior work [3,4], such as assumptions on the existence of cross-site leaks. As a result of this attack, the attacker is able to learn whether a specific individual visits the attacker-controlled website – a potentially serious privacy violation.

When a user visits the attacker-controlled website, the website uses an iframe, popunder, or tabunder to request a resource from a third-party website (i.e., the “leaky resource”). The response to this request, as well as the cache activity it generates in the user’s system, differs depending on the user state on the third-party website. An attacker monitoring the CPU cache side channel can analyze the cache patterns and learn whether the leaky resource was loaded successfully in the browser or not, and use this information to learn the identity of the visiting user. The attack can be scaled to identify thousands of users.

Whereas the iframe-based embedding method can be mitigated to some degree using web browser privacy settings (e.g. ETP Strict Mode in Mozilla Firefox), we are more concerned about the popunder and tabunder attack methods. Existing policies and standards are not effective in mitigating the threat in these two settings.

Interestingly, a similar issue was raised in 2019 by @annevk (issue #17) suggesting “It seems useful to tell a resource it's being loaded in an auxiliary browsing context as this means it can be controlled to some extent”.

The arguments made in issue #17 suggest to rely on Cross-Origin-Opener-Policy (COOP) for the problem of direct cross-window interactions. The issue was closed for lack of “additional scenarios in which the server would do something differently when loading in an auxiliary browsing context.” The attack scenario we describe IS a new scenario, in which COOP is not effective: the attacker indirectly learns private information cross-window or tab, even though it does not necessarily need a handle to the related tab or window.

We propose to extend the fetch metadata HTTP request headers, letting a website owner decide on how to respond to a potentially suspicious request based on the information provided about the context in which the request is made. We have three suggestions to add information at different levels of granularity. These suggestions would incrementally need more effort for implementation in web browsers:

1. The request is made from a popup window; it alerts the third-party website to some degree, so they can decide if making a request to a specific end point in a popup is expected. For example, a website may expect requests for third party authentication endpoints in popups. But it may not expect requests to leaky resources in popups, and so decide to prompt user action before navigating to the resource.

This information is a bit coarse-grained and also misses the tab-under variant of the attack.

2. The request is made from a tab/window where there exists an opener/openee relationship with another tab/window currently open, called a related tab/window. It would require the browser to check the existence of related tabs/windows at the time the request is being made.

This information alerts the third-party website about the possibility of an active attacker window/tab being present at the time the request is being made, where the attacker can leverage cache side channels to exfiltrate private information contained within the response sent by the target website.

3. The request is made from a tab/window where there exist related tabs/windows, with differing sites, at the time the request is being made.

This information is more fine-grained and raises alarms about the possibility of an active cross-site attacker being present. In terms of implementation, in addition to the check made in point 2 above, it would require another check on related tabs/windows for differing sites at the time the request is being made.

We will be happy to schedule a meeting to present our findings, and also to share proof-of-concept code demonstrating our attack.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1749129 [2] https://bugs.chromium.org/p/chromium/issues/detail?id=1285604 [3] Cristian-Alexandru Staicu and Michael Pradel. Leaky Images: Targeted Privacy Attacks in the Web. In USENIX Security Symposium, pages 923–939. USENIX Association, 2019 [4] Takuya Watanabe, Eitaro Shioji, Mitsuaki Akiyama, Keito Sasaoka, Takeshi Yagi, and Tatsuya Mori. User Blocking Considered Harmful? An Attacker- Controllable Side Channel to Identify Social Accounts. In EuroS&P, pages 323–337. IEEE, 2018

[annevk]

cc @arturjanc @lweichselbaum @cdumez @hemeryar

[hemeryar]

Just to clarify why COOP is not effective since I haven't taken the time to read the full paper. My understanding is that the CPU cache is exploitable across processes and that putting popup or tabs in different process will not make a difference?

[mjz3]

Yes, the CPU cache is exploitable across processes (by measuring the cache contention), and allows the attack page to learn information cross-site, indirectly, i.e. without needing a handle to the opened popup or tab. Since last level cache is shared among all processes, putting the popups or tabs in different process doesn't make a difference.