Preventing pool-party attacks

This is the thirteenth post in an ongoing, regular series describing new and upcoming privacy features in Brave. This post describes the result of a research collaboration between Brave Software and Soroush Karami at the University of Illinois at Chicago. We also thank Michael Smith and Deian Stefan, at University of California San Diego, for their help with this project. This post was written by Director of Privacy, Peter Snyder.

The TL;DR;

Brave has identified a new category of tracking vulnerability, forms of which are present in all browsers. We call this category of attack “pool-party” attacks because the attack uses collections (or “pools”) of limited-but-shared resources to create side channels. Trackers can then use these side channels to track users across sites and circumvent other privacy protections available in browsers.

Previous work (including the excellent XSLeaks project, and the recent XSinator paper) has identified similar attacks in this area. Our work builds on those projects by showing that pool-party attacks are more powerful, practical, and pervasive than previously realized, and that all browsers are vulnerable.

Even more concerning, we found that pool-party attacks can track users across profiles in Gecko-based browsers. Attackers targeting Gecko-based browsers can link activities in “private browsing”  windows with activities in “normal” browsing windows, linking someone’s private activities with their “true” identities.

Brave is already working on fixes for these issues, and we expect to begin shipping them to users in the next several weeks. Brave is also working with other browser vendors to address this problem. This blog post summarizes the findings of this research project; more details are available in this preprint version of the resulting research paper.

Background: Partitioning for Privacy

In response to user demands and legal requirements for better Web privacy, browsers have introduced more, and more robust, privacy protections. One important category of privacy protection is “partitioning,” where browsers prevent trackers from following you across sites by giving each site its own, distinct set of resources.

Partitioning protects users from the most common forms of cross-site tracking by preventing a tracker on one site from knowing you’re the same user on another site. Even if site-a.example and site-b.example both include a tracking script from tracker.example, partitioning prevents tracker.example from knowing the same person visited each site, preventing the tracker from linking your identity across sites.

Partitioning isn’t a panacea. There are many kinds of privacy harm that partitioning doesn’t protect users against (e.g., browser fingerprinting, cookie syncing from user identifiers, IP based tracking, etc.). Nevertheless, partitioning is a useful and important technique for protecting Web privacy.

Types of partitioning protections

	Brave	Chrome	Edge	Firefox	Safari	Tor Browser
DOM Storage	✅	❌	❌	✅	✅	✅
Network State	✅	—	—	✅	✅	✅

Because of the usefulness of partitioning, privacy-focused browsers have introduced different kinds of partitioning protections. The above table summarizes which browsers have which partitioning protections. DOM storage generally refers to APIs that sites are intended to use for storing application values. Network state generally refers to a wide range of other ways sites can store values implicitly in the browser, even if they’re not intended for applications to use in this way. ✅ indicates features that are available to all browser users by default, ❌ refers to features that are unavailable in these browsers, and “—” refers to features that are either disabled by default, or enabled only for a small percentage of users ¹. The fantastic privacytests.org project also summarizes the state of partitioning features in popular browsers.

More information about Brave’s DOM storage partitioning features can be found in the “Ephemeral Third-Party Site Storage” blog post in this series.

Problem: Pool-Party Attacks Defeat Partitioning Protections

Brave and our colleagues at University of Illinois at Chicago and University of California San Diego have found a variety of ways in which sites can circumvent the partitioning-based privacy protections in browsers. We call this category of attack “pool-party” attacks, since attackers are able to communicate (and so, track) across site boundaries by manipulating resources shared between sites.

While some instances of this attack have been identified in the past (such as the “connection pool” leak documented by the excellent XSLeaks project, and more recently, the terrific xsinator.com project), our work includes three important new findings:

• First, the attacks identified by previous work identified only specific instances of a broader category of attack; we find that browsers are rife with vulnerabilities to attacks in this category.
• Second, attacks in this category are more powerful than noted by some previous work; sites can use pool-party attacks to pass arbitrary data between sites.
• Third, pool-party attacks are not “theoretical”, they’re practical and realistically exploitable threats to Web privacy.

Pool-party attacks exist in all popular browsers, and can be exploited in many ways. Any resource pools, or resource limits, that are applied across site boundaries, can be exploited as a cross site tracking vector. Some examples of browser capabilities that can be abused to track Web users include WebSockets, server-sent events, limits on in-flight DNS requests, global limits on simultaneous HTTP requests when the browser is using a proxy, and restrictions around the Web Speech API, among others. Any API where the following conditions hold can be abused by trackers for cross-site tracking:

1. The resource is limited: sites can request resources from the pool until a limit is hit, after which sites are prevented from accessing further resources.
2. The resource is unpartitioned: different sites draw from the same limited resource pool.
3. Sites can probe the resource pool and learn whether the pool has been exhausted, or whether some resources remain.
4. Sites can consume resources from the pool without restriction (when the pool has not been exhausted).

In more technical terms, pool-party attacks are a class of side-channel that are present in all browser engines, and easier to exploit than most side-channel attacks. Most side-channel attacks target broadly-shared resources (e.g., CPU caches, memory caches, system interrupts), and so in practice are noisy and difficult to communicate across. Pool-party attacks, by contrast, target shared resources that are managed by—and specific to—the browser. This means that they’re much less noisy, and much easier to communicate across.

Solution: How to Defend Against Pool-Party Attacks

Brave is working with other browsers to protect users against pool-party attacks in general. Brave is also internally working on defenses to protect Brave users against the most practical pool-party attacks we’ve identified. We plan to start rolling these protections out to our desktop and Android browsers in the next few weeks.

Defending against pool-party attacks in general is difficult, since at root, computers always have limits on how many resources they can provide to sites. Computers have only so much memory, so much disk space, etc., and truly dedicated attackers will always be able to use these limitations to conduct pool-party style attacks. Short of the browser automatically closing when pages start behaving oddly, some form of this attack will always be possible.

That said, there are still steps browsers can take to make pool-party attacks impractical for trackers. Even if browsers can’t solve the problem at a fundamental level, browsers can at least make the attack uncommon and costly for trackers to conduct. Our paper describes several ways browsers can defend against pool-party attacks, but the general approach is to lift limits on high bandwidth resource pools. If trackers need to consume enough resources to start starving the entire system, the attacks will become noticeable to users. Web users would then stop visiting sites where pool-party attacks occurred, disincentivizing sites (and trackers hosted on sites) from conducting pool-party attacks in the first place.

Brave is actively planning our first set of pool-party attack defenses, and we expect to begin rolling out these defenses to Brave users shortly. Brave will also continue coordinating with other browser engine authors (e.g., Apple, Google, Mozilla) to design platform-wide defenses against pool-party attacks.