Pool-Party: Exploiting Browser Resource Pools as Side-Channels for Web Tracking
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Pool-Party: Exploiting Browser Resource Pools as
Side-Channels for Web Tracking
Peter Snyder∗,Soroush Karami† ,Benjamin Livshits‡ , and Hamed Haddadi‡
∗ Brave Software
pes@brave.com
† University of Illinois at Chicago
arXiv:2112.06324v1 [cs.CR] 12 Dec 2021
skaram5@uic.edu
‡ Brave Software, Imperial College London
{b.livshits,h.haddadi}@imperial.ac.uk
Abstract—We identify a new class of side-channels in browsers execute in realistic browsing scenarios to pose a threat to Web
that are not mitigated by current defenses. This class of side- users.
channels, which we call “pool-party” attacks, allow sites to
create covert channels by manipulating limited-but-unpartitioned In this work we demonstrate that current browser protec-
resource pools in browsers. We identify pool-party attacks in all tions (even those deployed by the most aggressively privacy-
popular browsers, and show they are practical cross-site tracking focused browsers) are insufficient. We demonstrate this by
techniques. defining a new category of techniques for constructing side-
In this paper we make the following contributions: first, channels, by exploiting the state of limited-but-unpartitioned
we describe pool-party side-channel attacks that exploit limits resource pools in the browser. Because such side-channels are
in application-layer resource pools in browsers. Second, we exploited by two parties colluding in the same resource pool,
demonstrate that pool-party attacks are practical, and can be we call this category of side-channel “pool-party” attacks.
used to track users in all popular browsers; we also share open
source implementations of the attack and evaluate them through “pool-party” attacks create side-channels out of explicit
a representative web crawl. Third, we show that in Gecko based- and intentional, browser-imposed limits on pools of resources.
browsers (including the Tor Browser Bundle) pool-party attacks When resource pools are limited (i.e., the browser will
can also be used for cross-profile tracking (e.g., linking user only allow pages to access resources up to some hard limit,
behavior across normal and private browsing sessions). Last, we after which requests for more resources will fail) and un-
discuss possible mitigations and defenses. partitioned (i.e., different sites consume resources from the
same pool), sites can consume or release those resources to
I. I NTRODUCTION leak information across security boundaries. Examples of such
boundaries include site-boundaries (e.g., the browser intends
Browser vendors are increasingly developing and deploying to prevent site A from communicating directly with site B) or
new features to protect privacy on the Web. These new privacy profile boundaries (e.g., the browser intends sites visited in a
features address the ways users are most commonly tracked on “standard” browsing session to not be able to learn about sites
the Web: partitioning DOM storage to prevent tracking from visited in an “incognito” browsing session). More generally,
third-party state, randomization or entropy reduction to combat sites can use these side-channels to conduct the kinds of cross-
browser fingerprinting, network state partitioning to prevent site tracking that the latest browser features were intended to
cache-based tracking, etc. prevent.
However, research has documented other ways Web users We identify practical “pool-party” attacks in all popular
can be tracked, though in ways that may be difficult to conduct browsers, both in each browser’s default configuration, and,
under realistic browsing conditions. Significantly among these for Chromium-browsers, also when non-standard, additional
are side-channels that can be constructed through timing sig- privacy-protecting features are enabled. We demonstrate “pool-
nals. These side-channels allow sites to communicate with each party” attacks in Chromium and Gecko based browsers through
other (or, even other applications) in ways not intended by the the limited-but-unpartitioned resource pool of WebSocket con-
Web security model. Significantly, such side-channels can be nections, and in WebKit based browsers through the Server-
used to reintroduce the kinds of cross-site tracking attacks the Sent Events resource pool. We further identify many other
above-discussed browser protections were designed to prevent. limited-but-unpartitioned resource pools in browsers that could
be leveraged for “pool-party” attacks. Examples of such pools
Browser vendors have responded to such side-channels in include certain kinds of resource handle (e.g., Web Speech
a variety of ways. Some side-channels (e.g., timing signals API), or limits on how many network requests (distinct from
from abusing HTTP cache state) have been largely addressed network connections) can be in flight at once (e.g., DNS
through platform wide improvements like network state parti- resolution), among others.
tioning. Other side-channels have been addressed (or, at least
mitigated) though other protections, like isolating sites in their Additionally, we demonstrate that “pool-party” attacks are
own OS processes. Others still have been left unaddressed, not just theoretical threats to user privacy, but practical threats,
possibly because they seem theoretical, or too difficult to and can be used to track users across sites. Further, we showthat in Gecko-based browsers (including the Tor Browser All four organizations were made aware of this submission,
Bundle), “pool-party” attacks can be used to create side- and were provided with pre-print versions of this paper.
channels across profiles, allowing sites to link behaviors in
“private browsing” modes with long term browser identities.
II. “P OOL - PARTY ” D EFINITION AND BACKGROUND
These findings are important for the development of
browser partitioning. All browser engines support some forms In this section we provide the background context for how
of partitioning: WebKit partitions DOM storage and some “pool-party” attacks relate to other Web tracking techniques in
kinds of network state, Gecko partitions DOM storage and general, and other methods of creating browser side-channels
network state, and Chromium partitions network state1 . Brave in particular. We also describe why existing browser protec-
has extended Chromium to also partition third-party. tions fail to protect users against “pool-party” attacks.
However, despite this welcome and difficult work, all This section proceeds by first defining what Web tracking
browser engines include multiple limited-but-unpartitioned re- is, then describes how websites can track users using “pool-
source pools that can be be leveraged for “pool-party” attacks. party” attacks. Next, we describe how “pool-party” attacks
We intend this work to be helpful in the further development relate to both i) other side-channels in browsers, and ii) con-
of partitioning-based privacy protections in browsers. ventional Web tracking techniques. We follow by explaining
why existing browser protections do not protect users against
“pool-party” attacks, and conclude by describing how this
A. Contributions work relates to a category of attacks previously known to be
More formally, in this work we make the following con- possible, but not previously shown to be practical.
tributions:
1) We define a new category of technique for creating A. Web Tracking and Cross-Site Tracking
side-channels in browsers. We call this category of This section gives a “working” definition of Web tracking.
side-channel ““pool-party” attacks”, and describe how Our goal in this definition is not to provide a formal, fully
the approach differs from the kinds of privacy attacks unambiguous definition (the phrase “Web tracking” is used
browsers currently aim to defend against; too broadly to likely allow for such a definition), but instead
2) We empirically evaluate how vulnerable browsers are to give a general, practical definition, to build on throughout
to “pool-party” attacks, and demonstrate that all popular the rest of this work.
browsers and browser engines are vulnerable to multiple
forms of the attack; In this paper, we use the term Web tracking to refer to
3) We provide two open-source, proof-of-concept imple- the practice of the browser-user being re-identified, across
mentations of our attack that work in all browsers 2 ; conceptual contexts, without the user’s consent. We use the
4) We perform a web-scale measurement to evaluate the word context broadly, to refer to the user executing a webpage
availability, bandwidth, and stability of “pool-party” at- in such a way that the webpage is not able to link the users
tacks, and find that “pool-party” attacks are a practical behavior or identity on that page, with the users behavior or
basis carrying out cross-site tracking attacks; identity on other webpages.
5) We discuss potential mitigation strategies for how
browsers could harden themselves against “pool-party” Contexts might be divided by time (e.g., a site re-
attacks. identifying a user revisiting the same site a week after first
visiting, despite the user clearing browsing data), application
(e.g., a site re-identifying a user in visiting a site in Safari
B. Responsible Disclosure as the same user who previously visited the site in Chrome),
We have presented our findings to the following browser profile (e.g., a site identifying that the visiting in an pri-
vendors (in alphabetical order): Apple, Brave, Google, Mi- vate/incognito browser session is the same user visiting the
crosoft, Mozilla, Opera, Tor Project. All reports were made site in a standard browser session) or sites (e.g., two sites
over 90 days in advance of this submission, as per the IEEE colluding to learn that browser sessions occurring on each site
“Ethical Considerations for Vulnerability Disclosure” guide- belong to the person). The commonality in all cases is the
lines. Microsoft and Opera responded that since the discussed users’ reasonable expectation that things that happen in one
vulnerabilities were in Chromium, they would wait for Google context are not readily known and available in another context.
to address the problem. The Tor Project similarly said they
would rely on Mozilla addressing the vulnerabilities. B. Description of “Pool-party” Attack
We are in ongoing discussion with the Brave, Google, and This work presents a new category of side-channels in
Mozilla security teams regarding the vulnerabilities identified browsers that we call “pool-party” attacks. “pool-party” attacks
in this work. Each of the three browser vendors have filed are side-channels constructed by two parties manipulating
security bugs and have expressed intent to address these leaks. the state of limited-but-unpartitioned resource pools to send
Apple has also shared that they are exploring how to fix the signals across security or privacy boundaries. Differences in
issue. browser architecture mean that browsers vary in terms of how,
1 At time of writing, network state partitioning is being tested for a portion and in how many ways, attackers can carry out “pool-party”
of Chrome users, as part of the engine’s “NetworkIsolationKey” feature attacks, but all popular browsers are vulnerable at time of this
2 Link to source code omitted for anonymization. writing.Algorithm 1 Toy example of a “pool-party” attack. Browser DOM Storage Network State
Site A: Ia ← random N bits Brave ⊕ ⊕
Chrome × ⊖
Site B: Ib ← empty string Edge × ⊖
while i ← Ia do Firefox ⊕ ⊕
Site A: Stop any playing videos Safari ⊕ ⊕
Tor Browser Bundle ⊕ ⊕
if Ia [i] = 1 then
Site A: Play a video
end if TABLE I: State partitioning features in popular browsers (in
Wait 5 seconds alphabetical order). ⊕, ⊖ and × indicate the feature being
if Site B is able to play a video then available by default for all, some, or no users, respectively.
Site B: Ib [i] = 1
else
Site B: Ib [i] = 0
end if on the Web, the less noisy the channel will be, and iii) the
end while larger the size of the resource pool, the higher the bandwidth
of the resulting communication channel.
This section describes how “pool-party” attacks work in C. Relationship to Other Side-Channel Attacks
general; Section IV gives specific examples of how this cate- “pool-party” attacks differ from other side-channel attacks
gory of attack can be executed in each browser. by targeting explicit, intentional, application-imposed limits.
How “Pool-party” Attacks Work. “Pool-party” attacks This differs from many other side-channel attacks in two ways,
work by manipulating pools of browser resources which are and generally makes “pool-party” attacks more practical.
limited (i.e., the browser restricts how many of the resource First, “pool-party” attacks target application-level re-
websites can open or consume) and unpartitioned (i.e., differ- sources, while many other side-channels target parts of the
ent contexts consume resources from the same pool). While system below, or at least distinct from, the application (e.g.,
the examples focused on in this work utilize limited-but- hardware restrictions like CPU caches, OS details like inter-
unpartitioned pools of network connections, browsers include rupt schedules or memory management, or language runtime
many other limited-but-unpartitioned resource pools that could features like garbage collection). This is significant because,
be similarly exploited, such as pools of file handles, subpro- the lower in the stack the attacker targets, the more likely it
cesses, or other resource handles. is (all other things being equal) that the targeted resource will
A “pool-party” attack occurs when parties operating in be shared with other actors on the system. This means that
distinct contexts (contexts the user expects to be distinct and lower-level side-channels are more likely to be noisy, and so
blinded from each other) intentionally consume and query the more difficult to communicate over.
availability of the limited resources in a resource pool, to Second, related but distinct, “pool-party” attacks target
create a cross-context communication channel. Each context browser-managed resources, resources that are, in most cases,
can then use the communication channel to pass an identifier, intentionally shielded from other applications on the system.
allowing each party to link the users behavior across the two This again reduces the chance that colluding parties will have
contexts. We note again that most commonly the two contexts to contend with a noisy, unpredictable side-channel.
considered here are two different websites running in the same
browser profile, but could also be the same (or different)
websites running in different browser profiles. D. Relationship to Other Tracking Methods
Demonstrative “Pool-party” Attack Example. Again, “pool-party” attacks do not fall neatly into the categories
Section IV provides details on specific ways of executing usually used to describe browser tracking techniques. This sub-
“pool-party” attacks in popular browsers, but we provide here section briefly describes the rough-taxonomy used in online-
a simplified example of how attacks in this category work. tracking research, and why “pool-party” does not cleanly fall
into existing categories.
For this toy example, assume a browser vendor wants to
improve performance by only allowing one video element to State-full Tracking. “State-full tracking” most commonly
be loaded at a time, across all sites. If a video is currently refers to websites using explicit storage APIs in the Web API
playing on any page, the site will receive an error if it tries to (e.g., cookies, localStorage, indexedDB) to assign identifiers
play a new video. to browser users, and then read those identifiers back in a
different context, to link the identity (or, browser behavior)
Algorithm 1 presents a toy algorithm where by two collud- across those contexts.
ing sites can trivially transform this optimization choice into
a cross-site tracking mechanism. Stateful-tracking also describes other ways websites can set
and read identifiers, by using APIs and browser capabilities not
While in practice this approach would be slow, we note intended for such purposes. Examples of such techniques in-
that it is only provided to demonstrate the concept, and actual clude exploiting the browser HTTP cache, DNS cache or other
attacks are provided in Section IV. We note three details ways of setting long term state (e.g., HSTS instructions [1],
though: i) the attack works for any limited-but-unpartitioned favicon caches [2], or, ironically, storage intended to prevent
resource, ii) the less common the resource pool’ed feature is tracking [3]).Browsers increasingly protect users from stateful tracking Browser Coordination Stability Uniqueness
by partitioning storage by context, mostly commonly be the Brave ⊕ ⊕ ⊕
effective-top level domain (i.e., eTLD+1) of the website. Chrome × × ×
Edge × × ×
Giving each context a unique storage area prevents trackers Firefox ⊕ × ⊖
from reading the same identifier across multiple contexts, and Safari × × ⊕
so prevents the tracker from linking browsing behaviors in Tor Browser Bundle × × ⊕
different contexts. Partitioning explicit storage APIs is often
referred to as DOM Storage partitioning. Partitioning caches TABLE II: Stateless tracking protections in popular browsers
and other “incidental” ways sites can store values is often (in alphabetical order). ⊕, ⊖ and × indicate the defense
called network state partitioning. Table I provides a summary is available by default, available but off by default, or not
of state partitioning in popular browsers. available, respectively.
Browser state partitioning strategies fail to defend against
“pool-party” attacks because “pool-party” attacks do not rely
on setting or retrieving browser state (at least not in the way In contrast to “state-ful” tracking techniques, “stateless”
state is generally discussed in this context, meaning the ways techniques do not require sites to be able to set and read
that sites can write state to the users profile). “Pool-party” identifiers across context boundaries, and so are robust to
attacks instead rely on implementation details of browser archi- storage partitioning defenses. Stateless attacks instead rely on
tecture, where device resources are limited-but-unpartitioned. three conditions to be successful:
While partitioning strategies could also be used to defend
against “pool-party” attacks, as discussed in Section V, certain 1) Coordination: code running in different contexts must
aspects of these attacks make partitioning approaches difficult know to query the same (or at least sufficiently large
in practice. intersection of) browser attributes.
2) Stability: the browser must present the same values for
Note on Chromium Partitioning Features. All analysis the same semi-distinguishing attributes across contexts
in this work uses a hardened, non-default configuration of (otherwise the browser will yield different fingerprints in
Chromium browsers. First, we disable third-party storage (i.e., different contexts, preventing the attacker from matching
block third party cookies). Second, we enable Chromium’s the two fingerprints).
network partitioning features. These features, which are 3) Uniqueness: the browser must present enough semi-
not enabled by default for most Chrome and Edge users distinguishing attributes to allow the site to accurately
are referred to generally as ‘‘NetworkIsolationKey’’ differentiate between users (otherwise the attack will
(NIK) 3 . When enabled, the NetworkIsolationKey feature confuse two different users as the same person)
causes Chromium to partition network state by top level
eTLD+14 , in a manner similar to, but not quite as compre- Browsers defend against “stateless” trackers by attacking
hensive as, Gecko based browsers. Importantly, the Network- any of these three requirements. A browser might prevent
IsolationKey system partitions network state, but not DOM coordination by blocking fingerprinting code on sites, or
storage. prevent stability by making the browser present different
attributes to different sites (such as in [5], [6]), or prevent
By default, NetworkIsolationKey features are disabled in
uniqueness by reducing the entropy provided by each attribute.
Chrome and Edge, though they are enabled for a small
Table II provides a summary of deployed “stateless” defenses
percentage of users as part of ongoing performance tests.
in popular browsers.
Brave Browser, which is also built on Chromium, enables the
NetworkIsolationKey system for all users. Browser defenses against “stateless” tracking techniques
fail to defend against “pool-party” attacks because of differ-
We choose to disable third-party state and enable the ences in the nature of the attack. “Stateless” techniques target
NetworkIsolationKey features in Chromium to demonstrate stable semi-distinguishing browser characteristics which are
that Chromium-based browsers are vulnerable to “pool-party” set by a page’s execution environment. “Pool-party” attacks,
attacks, even in highly hardened configurations. in contrast, are enabled by sites consuming and reading the
Stateless Tracking. “Stateless tracking,” (also often called availability of limited resources in the browser across execution
“browser fingerprinting”) refers to the category of Web track- contexts. Therefore, unsurprisingly, browser defenses against
ing techniques whereby the attacker constructs a unique iden- “stateless” tracking provide no protection against “pool-party”
tifier for the user by combining a large number of semi- attacks.
distinguishing browser and environmental attributes into a XS (Cross-Site) Leaks. “Pool-party” attacks are most
stable, unique identifier. Examples of such semi-distinguishing similar to a category of attack loosely called “XSLeaks” 5 ,
features include the operating system the browser is running a broad collection of ways sites can send signals to each other
on, the browser version, the names and the number of plugins in ways generally unintended by browser vendors. However,
or hardware devices available, and the details around the we note that in contrast to “state-ful”, “stateless,” “pool-party”
graphics and audio hardware present, among many others [4]. attacks, XSLeaks do not have a common cause or remedy;
instead, XSLeaks can be largely thought of as a catchall
3 https://github.com/shivanigithub/http-cache-partitioning#choosing-the-partitioning-key
4 Chromium’s NetworkIsolationKey actually employs a more complex sys- for cross-site (or cross-context) techniques that do not not
tem for determining the appropriate cache key for a resource than just the top fit in another category. Examples of XSLeaks include timing
level frame’s eTLD+1, but for all purposes relevant to this paper, the system
can be simplified to “top level frame’s eTLD+1” without error. 5 https://xsleaks.dev/channels stemming from a variety of causes, unintended side hit, after which sites are prevented from accessing more
effects of experimental browser features 6 , or misuse of other resources, in a manner the site can detect.
browser APIs 7 . 2) The resource pool is unpartitioned, meaning that differ-
ent contexts (e.g., sites, profiles, etc.) all draw from the
The lack of a common cause of XSLeaks makes it im-
same global resource pool. Put differently, it cannot be
possible to generalize about defensive strategies or deployed
the case that each context gets its own distinct resource
browser defenses. Recent work in this area has identified ways
pool.
sites can leak information across browser-imposed boundaries,
3) Sites can probe the state of the resource pool, to distin-
including through unintended side effects in how browsers
guishing between whether the pool has been exhausted,
handle errors, implement COOP 8 , CORP 9 , and CORB 10
or if some resources remain.
policies, or limit the length of redirection chains, among many
4) Sites can consume resources from the pool without
other signals [7].
restrictions, as long as the pool is not already exhausted.
We note though that “pool-party” attacks are most common
to the “connection pool” attacks identified by the XSLeaks Any resource pool where the above four criteria are met can
project 11 . This work makes the following contributions beyond be transformed into a covert communication channel between
the issues documented by the XSLeaks project, and the related any two parties sharing the resource pool.
work done by Kinttel et al. [7]. We have identified resource pools matching the above
First, this work identifies and defines a larger category of four criteria in current versions of all popular browsers, even
attack, where by any limited-but-unpartitioned resource pool browsers that particularly emphasize their privacy features
can be transformed into a side-channel (and so, a tracking (e.g., Brave Browser, Tor Browser Bundle), and even when
technique). The connection pools attack documented by the browsers are “hardened”, by enabling non-default, privacy-
XSLeaks project is a subset of the larger category of attack focused features (as discussed in Section II-D).
discussed in this work. While limited-but-unpartitioned con- We now proceed by qualifying the un-optimized, proof-of-
nection pools can be used to conduct “pool-party” attacks, concept state of the algorithm, and then conclude by presenting
“pool-party” attacks can also be carried out in other browser and explaining the generic algorithm itself.
resource pool (e.g., resource handles, subprocess pools, etc).
Section V-A identifies resource pools in browsers that can A. Proof-of-Concept Status
be exploited for “pool-party” attacks that are not connection
pools. Before walking through the algorithm, we wish to empha-
size that the current algorithm is intended as a proof-of-concept
Second, we demonstrate that attacks of this type are not demonstration of “pool-party” attacks, and could be improved
just theoretically possible, but are practical, and are real-world with a number of practical, trivial optimizations. Such opti-
threats to Web privacy. mizations might include compressing messages before sending
Third, the presented “connection pool” attack relies on them, increasing the message transmission rate by including
abusing the connection pool to create timing channels, while lookup tables in the sending and receiving code, or extending
“pool-party” attacks utilize the number of available resources the protocol to be robust to noise (i.e., other sites using
in the pool to create the communication channel. This resources in the resource pool), among others. The simple
seemingly-small difference is significant. Using the amount approach in Algorithm 2 is only intended to demonstrate
of availability of resources in the pool as the communication that the attack is generic and practical, even in the naı̈ve
channel makes the attack more robust to noise introduced from implementation provided.
other sites, and means that mitigations against one form of the
attack may not apply to the other. B. “Pool-party” Algorithm
We present a generic protocol for conducting a “pool-
III. G ENERIC “P OOL - PARTY ” ATTACK A LGORITHM party” attack over limited-but-unpartitioned resource pools
In the previous section we presented the category of “pool- in all browsers. This protocol is presented as Algorithm 2,
party” attack in the abstract, explained why “pool-party” and provides a generic way a site can use a limited-but-
attacks are different from other attacks discussed previously unpartitioned resource pool to track users, by passing messages
in the literature, and why current browser defenses fail to across site boundaries (in a way not intended by any browser
protect against “pool-party” attacks. In this section we present vendor).
a generic algorithm for conducting “pool-party” attacks, which Protocol Inputs. The algorithm takes two inputs. The first
can then be applied to any resource pool in a browser where input is the limited-but-unpartitioned resource pool which the
the following conditions are met. sending site and the receiving site will use to communicate.
1) The resource pool is limited, meaning that sites can The size of the resource pool (i.e., the number of resources
request resources from the pool until a global limit is in the pool available) is stored as POOL_SIZE. Any resource
pool would work, as long as (a) it is limited-but-unpartitioned,
6 e.g., https://xsleaks.dev/docs/attacks/experiments/scroll-to-text-fragment/ (b) sites can probe whether there are any resources still
7 e.g., https://xsleaks.dev/docs/attacks/window-references/
available in the pool, and (c) sites can arbitrarily consume
8 https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy
resources from the pool.
9 https://developer.mozilla.org/en-US/docs/Web/HTTP/Cross-Origin Resource Policy (CORP)
10 https://fetch.spec.whatwg.org/#corb The second input to the algorithm is the message to be sent
11 https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/ over the channel, which is a binary string of arbitrary length.Algorithm 2 General algorithm for a “pool-party” attack. the size of the communication channel, POOL_SIZE, as the
Inputs. number of resources in the resource pool determine how
POOL SIZE ← size of resource pool much information can be sent across the channel at a time.
MSG ← binary string to transmit The sending site then splits their message into PKT_SIZE
sized chunks, yielding a vector of bit-strings each of size
1. Setup. PKT_SIZE. Finally, the receiving site constructs an empty
PKT SIZE ← ⌊log(P OOL SIZE)⌋ buffer, RECV_MSG, to stream the received message into one
CHUNKS ← MSG split into packets of size PKT SIZE packet at a time.
RECV MSG ← empty string Step Two: Determining Initial Sender and Receiver.
Next, the two sites determine which site will be the initial
2. Determining Initial Sender and Receiver. sender and which the receiver. This negotiation is needed be-
Both sites: try to consume > 50% of resources in pool until cause, again, neither site initially knows what other colluding
all resources are exhausted site(s) may be open and available to communicate with, and
if If “Site A” is able consume over > 50% of pool then thus no way of assigning roles in the protocol.
SENDER ← “Site A”
RECEIVER ← “Site B” Sites determine which site is the initial sender and the
else initial receiver by racing to exhaust the resource pool. The
SENDER ← “Site B” site that is able to consume more than 50% of resource in the
RECEIVER ← “Site A” pool assigns itself the role of initial sender; the site that is
end if prevented from requesting the 50% + 1 resource assigns itself
Sender: consumes 100% of pool resources as the initial receiver.
Receiver: releases all pool resources
Once the parties have determined their roles in the protocol,
3. Sending Data. the receiver releases the pool resources it holds, and the sender
if SELF == SENDER then keeps consuming resources until the pool is exhausted.
for c ← CHUNKS do Step Three: Sending Data. The third step of the protocol
SEND INT ← binaryToDecimal(c) is where passing data across context (i.e., site) boundaries
Release SEND INT resources from pool occurs. The sender and the receiver participate in this step of
Probe pool until all resources are exhausted the protocol as follows.
Probe pool until resources are available
Consume all resources in pool The sender manipulates the state of the resource pool as
end for follows for each c in their CHUNKS vector (recall that CHUNKS
Release all held pool resources is a vector of binary strings, each of length PKT_SIZE).
else if SELF == RECEIVER then For each c, the sender first interprets the binary as positive
loop integer representation (e.g., 0010010 becomes 18, etc), which
Probe pool until resources are available is stored as SEND_INT. The sender then releases SEND_INT
Consume all resources in pool resources from the pool, and then probes the pool until the
RECV INT ← number of consumed resources sender observes the pool is exhausted, indicating that the
if RECV INT >= 2P KT SIZE + 1 then receiver is reading from the channel. The sender continues
Break out of loop probing the pool until there are resources available again,
end if which indicates that the receiver has finished reading from
RECV STR ← decimalToBinary(RECV_INT) the channel and is ready for the next chunk of data. If the
RECV MSG k = RECV STR sender has finished sending their message, the sender releases
Release all held pool resources all resources in the pool and proceeds to the next step in the
end loop protocol. Otherwise, the sender consumes all resources in the
end if pool and repeats the current stage in the protocol.
Simultaneously, the receiver begins this stage of the pro-
4. Exchanging Roles. tocol by probing the resource pool until it observes that
Each party swaps roles. The sender becomes the receiver and there are available resources in the pool. Once the receiver
vice versa. Continue protocol from step 3. Sending Data. is able to claim a resource, the receiver tries to consume as
many resources as possible, which will be the SEND_INT
number of resources released by the sender, and stores this
Note that sites begin the protocol without knowing which site as RECV_INT. If RECV_INT is greater than or equal to
will be the initial sender and which site will be the initial 2P KT SIZE +1, the receiver knows the sender has released all
receiver (though the protocol could trivially be extended to of the resources in the thread pool, indicating that the sender
enforce such a restriction). The binary string to be transmitted has finished transmitting. 12 If so, the receiver will move on
is stored as MSG. to the next step of the protocol. Otherwise, the receiver will
encode RECV_INT in the inverse manner the sender used (e.g.,
Step One: Setup. Next, several intermediate values are
calculated by either or both parties. Both parties calculate the 12 Recall that, by construction, the sender is not able to obtain
size of each packet that will be sent across the communication 2P KT SIZE + 1 or more resources, and so the receiver can be certain that
channel. This value, stored as PKT_SIZE, is determined by values in this range are not data the sender is attempting to transmit.18 becomes 0010010), and concatenates the result onto the Engine Browsers
receiver’s RECV_MSG. The receiver then releases all resources Chromium Brave, Chrome, Edge
it holds, and repeats the above process. Gecko Firefox, Tor Browser Bundle
WebKit Safari
We note one edge case not yet handled by the algorithm.
As is, the algorithm presents a problem when the sender TABLE III: Summary of which popular browsers use which
wishes to send a chunk of data with decimal equivalent of underlying browser engine, in alphabetical order.
zero. This is a problem because, in its current form, the
sender would send this chunk by releasing zero resources,
which the receiver can not distinguish from no signal at all. Browser Pool Size Tracking Capability
We account for this ambiguous case by reserving the value
Brave WebSockets 255 Cross-site
2P KT SIZE (one greater than the maximum value a packet Chrome WebSockets 255 Cross-site
can otherwise encode) to signal a packet of all zeros. For Edge WebSockets 255 Cross-site
example, if PKT_SIZE is 7, then the sender would signal Firefox WebSockets 200 Cross-site & Cross-profile
Safari Server-Sent Events 6 Cross-site
a chunk of 0000000 by releasing 128 threads, encoding the Tor Browser Bundle WebSockets 200 Cross-site & Cross-profile
value 10000000 into the resource pool.
Step Four: Exchanging Roles. Finally, if desired, the TABLE IV: The capability used to conduct the “pool-party”
two parties can exchange roles to pass data in the receiver to attack in each browser, the size of the resource pool being
sender. This is trivially accomplished by each party assuming exploited, and what contexts can be linked through the attack.
the opposite role, and continuing again from step 3. Otherwise,
if there is no more data to transmit, both parties can abort
the protocol. Note that the protocol itself does not provide
a mechanism for the parties to indicate whether they wish to (encoded as a bit string) across contexts. And third, we
continue or end the protocol, though parties could easily signal measure the stability of the particular “pool-party” attack, by
such through the contents of the messages being passed. conducting a representative crawl of the Web, and measuring
how frequently we observe how much the communication
IV. E VALUATION OF “P OOL - PARTY ” V ULNERABILITIES channel is used on the Web currently (and so, how much noise
IN P OPULAR B ROWSERS an attacker might have to contend with when conducting the
attack).
In the previous section we presented a generic algorithm
for turning limited-but-unpartitioned resource pools into cross-
context communication channels, which in turn can be used to A. Browser Selection
cookie-sync and track users across the Web. In this section we
demonstrate two examples of such limited-but-unpartitioned We group browsers by their underlying rendering engine.
resource pools in popular browsers, and measure how ex- We did not identify any instances where different browser
ploitable and practical they are for cross-site tracking. engines, using the same engine, were differently vulnerable.
Specifically, we show that practical forms of “pool-party” All attacks that worked against Firefox also worked against
attacks can be carried out in all popular browsers. In Chromium Tor Browser Bundle, and all the attacks that worked against
and Gecko-based browsers, we demonstrate this vulnerability Chrome also worked against Brave and Edge, etc. We note
by exploiting those browsers limited-but-unpartitioned imple- that enabling or disabling Chrome’s non-default partitioning
mentation of the WebSockets API 13 . Safari’s implementation features (discussed in Section II-D), and enabling or disabling
of the WebSockets API is not limited-but-unpartitioned (there third-party storage in Chromium, had no effect on how vul-
is no explicit limit on the number of websocket connections nerable Chromium-based browsers were.
that can be open). Instead, we demonstrate Safari’s vulnerabil- A brief summary of the browsers and their underlying en-
ity to “pool-party” attacks through the browser’s implementa- gines, and hence the applicability of the below measurements,
tion of the Server-Sent Events (SSE) API 14 . Safari’s SSE pool is presented in Table III.
is much smaller than Chromium or Gecko’s websocket pool
(6 connections, versus 255 or 200 connections, respectively),
which makes the attack slower in Safari, though still practical. B. Attack Availability
For both of these attack vectors, we conduct three mea- Methodology. We measure the availability (and so, ex-
surements to analyze the practicality and severity of the attack. ploitability) of each attack by first examining the source
First, we discuss the availability of the attack in each browser code of each browser engine and identifying limited-but-
engine, meaning we present the size of the resource pool in unpartitioned resource pools. We then implemented attacks
each browser engine and what kinds of context-linking are against each browser based on the algorithm presented in
possible using that resource pool in each browser engine (e.g., Section III, implemented in JavaScript 15 . We then examined
cross-site communication, cross-profile communication, etc.). whether we could use the relevant resource pool to create a
Second, we measure the bandwidth of the communication side-channel and communicate across site boundaries, across
channel, by measuring how long our unoptimized, proof- profile boundaries, or both. Importantly, we test whether the
of-concept algorithm takes to transmit a unique identifier attack technique can be used to communicate between a
13 https://developer.mozilla.org/en-US/docs/Web/API/WebSockets API
14 https://developer.mozilla.org/en-US/docs/Web/API/Server-sent events 15 Link to source code omitted for anonymization.standard-browsing profile, and a “private browsing mode” open two pages on two different domains we controlled.
profile 16 . Each page includes an implementation of the relevant “pool-
party” attack (SSE in Safari, websockets in all other browsers),
Results. Our availability measurements yielded several implemented through JavaScript included in the page. We then
significant findings, summarized in Table IV. measure how long it takes to conduct the second and third steps
First, we were able to identify exploitable limited-but- of Algorithm 2. We then conduct this measurement 50 times,
unpartitioned resource pools in all browsers, which we were using a clean browser profile for each measurement.
successfully able to exploit through “pool-party” attacks. As We note that we were unable to conduct these measure-
noted, the resource pools targeted in each browser engine ments in the Tor Browser Bundle, because of issues with using
differ. We were able to use the relatively large WebSockets Selenium to automate the browser. However, manual testing
connection pool in Chromium and Gecko based browsers to anecdotally suggests that attacks against the Tor Browser
conduct “pool-party” attacks. Safari’s WebSockets implemen- Bundle behaves similarly to Firefox, after accounting for the
tation was not exploitable, since WebKit does not restrict how slowdown induced by the Tor network.
many WebSocket connections can be opened simultaneously.
Safari’s implementation of the SSE API, though, was ex- Results. We report the results of our bandwidth mea-
ploitable (Chromium and Gecko’s implementation of the SSE surements in Table V. Times are reported in seconds, and the
API was not exploitable). aggregate values are reported over 50 independent executions
for each measurement.
Second, and importantly, we found that Gecko-based
browsers (i.e., Firefox and the Tor Browser bundle) were We note several significant findings. First, we find that
vulnerable to “pool-party” attacks in a way more concerning attacks are practical, even given the current, unoptimized
than other browser engines. While “pool-party” attacks can be version of the attack described in Algorithm 2. Even in its
used for cross-site tracking in all browsers, in Gecko-based current form, the attack could be carried out between pages
browsers “pool-party” attacks can be used to track users that are left open for a moderate amount of time, either because
across profiles. Significantly, this means that, in Gecko-based they get lost in a browser users ever-growing collection of tabs,
browsers, sites can conduct “pool-party” attacks between pri- or because the site is intended to stay open for a long time
vate browsing sessions and standard browsing sessions. More (e.g., sites that function and email clients, instant messaging
concretely, a site running in a private browsing window can applications, video streaming sites, etc). Simple optimizations
collude with a site running in a standard browsing window, and (introducing parallelism into websocket or SSE construction
identify both sessions as belonging to the same person. This or teardown steps, message compression, etc) would further
is particularly concerning since it violates the core promise reduce the amount of time needed to conduct such attacks.
of a private browsing session; that behaviors conducted using
a private browsing are “ephemeral”, and cannot be linked Second, there is an unsurprising but important trade-off
other accounts or behaviors a user maintains. Additionally, this between resource pool size and bandwidth. Attacks utilizing
vulnerability undermines the work and research that has been small resource pools (such as the Safari attack over SSE
done to strengthen private browsing modes in browsers (for resources) can be setup faster (since there are fewer resources
example, [8], [9], [10]). the parties need to consume to coordinate), but then take
longer to transmit messages (since communication in the pool
Third, we found no variation of how vulnerable browsers is constrained). Communicating through larger resource pools
are, within the same browser engine. Though browser vendors (such as Chromium’s WebSocket implementation), conversely,
like Brave and the Tor Foundation add many privacy features takes longer to setup, but then can transmit data faster. More
that other browsers using the same browser engine lack, the generally, smaller resource pools can send smaller messages
Brave Browser and Tor Browser Bundle were just as vulnerable faster, while larger connection pools can send larger messages
to “pool-party” attacks as other browsers based on Chromium faster (since the one-time setup cost reduces in significance as
or Gecko, respectively. the number of messaging rounds increases).
Third, we observe very little performance difference be-
C. Attack Bandwidth tween different browsers using the same browser engine, at
Methodology. We measured the bandwidth of each attack least within the three Chromium browsers included in this
by measuring how long our non-optimized “pool-party” attack measurement.
takes to transmit a 35-bit string across site boundaries.
D. Attack Stability
We selected a 35-bit string for two reasons. First, because
it is over 33-bits, or what is needed to uniquely identify Methodology. To evaluate the stability of the “pool-party”
the approximately 7.9 billion people on the planet, and two, channels discussed in this section, we measured how often
because it aligns cleanly with the 5-bit packet size used in these resource pools are used by sites for other purposes,
WebSocket experiments. from the intuition that resource pools that are less commonly
used (and so more frequently fully available) are easier to
We conduct each measurement as follows. First, we instru-
convert into side- channels. Put differently, if sites are already
ment each browser using Selenium, and have each browser
participating in a resource pool for benign purposes, then other
16 This feature goes by different names in different browsers, but generically sites intending to use it as a covert communication channel
refers to the ability to run the browser in a way where stored values only last have to contend with more noise and uncertainty, and thus
the lifetime of the browsing session. communication will be more difficult.Setup Phase Sending Phase Total
Browser Method Mean Median Std Dev Mean Median Std Dev Mean Median Std Dev
Brave WebSockets 59.9 59.3 3.3 50.2 50.0 0.8 110.1 109.4 3.5
Chrome WebSockets 61.6 60.4 4.7 46.4 46.0 1.8 108.0 106.5 5.8
Edge WebSockets 58.6 58.3 2.5 45.9 45.8 1.0 104.5 104.2 2.9
Firefox WebSockets 69.4 68.6 8.1 64.8 63.0 15.4 134.2 133.0 17.8
Safari SSE 19.2 16.5 20.1 163.9 163.8 2.1 183.0 180.0 20.4
TABLE V: How long it took to transmit a 35-bit string across site boundaries using a “pool-party” attack. Values are over 50
measurements, and reported in seconds.
WebSockets SSE
Success Rate # of Sites % of Sites # of Sites % of Sites
High Popularity Sites 93.3% 669 7.2% 51 0.5%
Less Popular Sites 95.7% 816 8.5% 19 0.4%
TABLE VI: Measurements of how much resource contention we saw in the resource pools used for the “pool-party” attacks
measured in this work. The “High Popularity” measurements are taken on the Alexa 10k. “Less Popular” measurements are
taken from 10k sites randomly sampled from sites ranked 10k + 1 through 100k in the Alexa top site rankings.
We measured the stability of our “pool-party” attacks by Third, we had our crawler visit the landing page of each
examining how often Web sites use WebSocket and/or SSE site. If the site failed to load for any reason (e.g., invalid
capabilities; the less “background” use of these APIs on the certificate, server is offline, etc.) we noted the measurement as
Web, the less noise an attacker would need to contend with, an error. Otherwise, we let the page execute for 10 seconds,
and so the more stable the “pool-party” attack. We conducted noted the number of WebSocket and SSE connections used,
these measurements through the following steps. and then closed the page. Each measurement was taken in a
new browser profile.
First, we built a Chrome-based crawler, using the Pup-
peteer 17 automation framework. This crawler was constructed Results. The results of our stability measurements are
to measure how many WebSockets connections, and how many summarized in Table VI. The results lead us to conclude
SSE connections, were used during the execution of the page that the attack could practically be carried out, which a high
success rate. The vast majority of sites do not use either of
We measured how many WebSockets were used by hooking these browser features, meaning that in the common case sites
into already existing functionality in Chrome. Chrome records could use the resource pool without bother from other pages.
whenever a website tries to create a WebSocket connection in The probability that, for two randomly selected sites, neither
a histogram, along with a wide range of other browser per- page is using WebSocket connections is 86.1% and 83.2% for
formance measurements. These measurements can be viewed popular and less popular sites, accordingly. The odds are even
by visiting chrome://histograms in a Chromium-based more favorable (for the attacker) for SSE connections. The
browser, or programmatically through Chrome’s devtools probability that neither of two randomly selected sites are using
API 18 . SSE connections is > 99.0% and > 99.2% for popular and less
We measured SSE use through an extension that modifies popular sites, respectively.
the browser’s EventSource 19 prototype to log whenever We note again that these success probabilities are only
a page instantiates a new EventSource object, or calls the for the simplistic version of the algorithm presented in Sec-
object’s close() 20 method. tion III-B, which is not able to account for other actors drawing
Second, we deployed our crawler on two sets of websites, resources from the resource pool. A slightly more sophisticated
to measure whether there were differences in WebSocket or version of the algorithm, one that could account for some noise
SSE use between popular and less popular sites. We con- on the channel, would have even higher odds of success.
structed these sites as follows: Measurement Limitations. We briefly note some of the
limitations of this crawl methodology, and why we think they
1) The High Popularity 10k set consists of the 10k most do not significantly impact the conclusions discussed above.
popular websites, as determined by the Alexa Top Sites
rankings. First, we note that this crawl could be made more robust
2) The Less Popular 10k set comprises a random sampling in a number of ways, such as crawling child pages on the site
of 10k websites taken from sites ranked 10k+1 through or interacting with the page. Web measurements exist on a
100k, according the Alexa Top Sites rankings. spectrum from extremely simple (e.g., measuring a website
using only curl 21 ) to extremely complex (e.g., multiple
17 https://github.com/puppeteer/puppeteer measurements, from multiple IPs, from multiple browsers).
18 https://chromedevtools.github.io/devtools-protocol/tot/Browser/#method-getHistograms
The measurements in this subsection exist between those
19 https://developer.mozilla.org/en-US/docs/Web/API/EventSource
20 https://developer.mozilla.org/en-US/docs/Web/API/EventSource/close 21 https://curl.se/extremes. WebKit. We identified far fewer additional limited-but-
unpartitioned resource pools in WebKit than in other browser
Second, we note that in practice, sites colluding in a “pool- engines. We did not identify any additional attack vectors in
party” attack would need to contend with the union of all open Safari (the most popular browser built on WebKit). However,
sites accessing resources from the relevant resource pool, and other, less popular browsers are also built on WebKit, and some
not simply the parties committing the “pool-party” attack. The of these introduce additional limited-but-unpartitioned resource
numbers resulting from our methodology are a lower bound pools. For example, the GTK-based version of WebKit 25
on how noisy the given resource pool would be, and attackers includes a built-in DNS resolver that has a global limit of
might need to implement ways of communicating over noisy 8 requests at a time, and a pre-fetch cache with a limit of 64
channels. hosts.
That said, we believe that our approach is sufficient for
the purposes of this work. Our aim is not to precisely under- B. Defenses and Constraints
stand the behavior of particular webpages, but get a general,
aggregate understanding of how often, and how much, these Defending against “pool-party” attacks in browsers is diffi-
resource pools are used on the Web for non-“pool-party” attack cult since, at root, systems will always have limited resources,
purposes. We note too that our numbers are similar to those and thus some underlying limited-but-unpartitioned pool that
recorded by the Chrome project’s public telemetry (which finds can be exploited by a sufficiently motivated party. Currently
that WebSockets and SSE are used on less than 7% 22 and browser resource limitations are mostly explicit and inten-
1% 23 of popular websites, respectively), giving us further tional, but even if browsers removed such limits (e.g., limits
confidence that our methodology is sufficiently robust. on WebSocket connections), the underlying system would
necessarily have a global limit, either explicitly (e.g., OS
imposed limitations on open network sockets) or implicitly
V. D ISCUSSION
(e.g., systems have a finite amount of memory, and so
A. Additional Attack Vectors unavoidably can only maintain a finite number of network
sockets).
In this work we demonstrated that “pool-party” attacks are
possible and practical in all popular browsers, by exploiting However, even if “pool-party” attacks will fundamentally
the limited-but-unpartitioned implementations of WebSockets always be possible, browsers can still take steps to limit how
and Server-Sent Events. However, there are many other “pool- practical such attacks might be.
party” attack opportunities in current browsers. This section
details some additional APIs and browser capabilities that can One approach is to lift browser-imposed limits on resource
be converted into side-channels though “pool-party” attacks. pools where applicable, and require attackers to contend with
We do not intend this to be a comprehensive list; we expect that much larger system maintained resource pools. This would
there are many more “pool-party” attack vectors in browsers. make attacks much more obvious to the user, who would
We identified the below browser capabilities and APIs as likely notice their system slowing down or other applications on the
exploitable by “pool-party” attacks based on their implemen- system impacted while the attack was being carried out. Such
tations in Gecko, WebKit and / or Chromium, though we did detectability might deter attackers, at least in the common
not build attacks to test the exploit-ability of all listed APIs. case. Relying on the OS or system level limits would also
make attacks more difficult to carry out. For example, the
Chromium. Chromium’s DNS resolver has a global, system network connection pool will be much “noisier” than
unpartitioned limit of 64 simultaneous requests, which could the browser’s WebSocket pool, making it much more difficult
be exploited by an attacker that can control the response to use the resource pool as a reliable covert channel.
time of DNS queries to a nameserver they control. Second,
when Chromium browsers are configured to use an HTTP Second, browsers could take the opposite approach, and
proxy, they impose a global limit of 32 network requests at instead of dramatically widening the size of resource pools,
a time. Third, several APIs in Chromium are thin-wrappers browsers could maintain existing resource caps but partition
around OS-provided systems, and maintain a single global resource pools the same way browsers increasingly partition
handle to the system process, effectively creating limited-but- DOM storage and network state (see Section II-D). If resource
unpartitioned pool of size one. Though small, this would be pools were partitioned by site, a site would not learn anything
sufficient to carry out attacks like the toy example given in by exhausting its resource pool; the resource pools for other
Section II-B. Chromium’s implementation of the Web Speech sites would be unaffected. A determined attacker could regain
API 24 is one such example. the ability to conduct a “pool-party” attack by controlling a
large number of sites, and using them to collectively drain the
Gecko. Browsers built on Gecko have many of the same resource pool. Nevertheless, partitioning resource pools by site
additional attack vectors as Chromium based browsers. Gecko would make “pool-party” attacks significantly more difficult
similarly has a global limit on the number of DNS requests for an attacker to carry out.
that can be in the air at the same time, and a lower limit on
the number of network requests that can be open when using Third, browsers could combine these two approaches, and
a HTTP(S) proxy. simultaneously remove global limits on the size of resource
pools, but limit the number of resources each site or context
22 https://chromestatus.com/metrics/feature/timeline/popularity/1149 and use. Such a hybrid approach would achieve some of the
23 Sum of https://chromestatus.com/metrics/feature/timeline/popularity/1480 benefits of both of the above approaches.
and https://chromestatus.com/metrics/feature/timeline/popularity/1479
24 https://developer.mozilla.org/en-US/docs/Web/API/Web Speech API 25 https://trac.webkit.org/wiki/WebKitGTKYou can also read
