More specifically, we show that an attacker-controlled webpage can know which other pages from the same websites a user is currently browsing, retrieve sensitive information from these pages, and even recover login credentials (e.g., username and password) when they are autofilled. We further demonstrate that the attacker can retrieve data from Chrome extensions (such as credential managers) if a user installs a malicous extension.
We deployed Spook.js on a Tumblr blog, targeting a password that was autofilled into Tumblr's login page by Chrome's built-in credential manager. We show that our blog can be rendered by the same Chrome process as the login page, and that Spook.js can consequently recover the password.
This time, we packaged Spook.js as a Chrome extension. We show that under certain conditions, multiple extensions may be consolidated and executed from the same process. We take advantage of this behavior to read the memory of the LastPass credential manager extension, and recover the master password of the target's vault.
No, you can continue using Chrome extensions. While we have found issues with Chrome's extension isolation, Spook.js is still relatively hard to mount and requires substantial side channel expertise. Moreover, in response to our work, Google has deployed changes to how extensions are laid out in memory, which prevents them from being affected by Spook.js. See the 'What countermeasures are available?' question for more information.
Modern processors improve performance by predicting if a branch in program code will be taken or not, especially if the branch's condition cannot be computed yet. If a processor predicts that a branch will be taken, it will speculatively start executing the instructions within the branch, even though it has not calculated the outcome of the branch. If the branch is actually taken, its instructions have been partially computed already, bringing in the performance benefits. On the contrary, if the branch is actually not taken, the processor attempts to roll back the instructions it speculatively executed.
The majority of attacks on computer systems take advantage of vulnerabilities in the algorithms they use. For example, they exploit bugs, buffer overflows or bad random number generators in order to break the security of the targeted system. In contrast, a side channel attack leverages the hardware of the system in order to attack it. Common side channel examples include monitoring the system's power consumption, electromagnetic radiation, and even sound.
One popular source of side channels (which we also use for Spook.js) is the processor's cache. The cache is a hardware component which stores recently used data in memory to provide faster access. Although this speeds up performance, an attacker can measure the time it takes to retrieve certain data and thus infer if another program has accessed it. This allows the attacker to retrieve the target's memory access pattern, which in many cases is highly correlated with the data processed by the target. Finally, cache side channels are useful as a building block in speculative and transient execution attacks, such as Spook.js, Spectre and Meltdown.
Spectre is a hardware vulnerability that affects nearly every general purpose processor. This includes nearly all modern Intel, AMD, and Apple CPUs, both for desktops and laptops. At a high level, the majority of recent processors predict the outcome of a branch if it cannot be computed quickly, and continue executing instructions along the prediction. If the prediction is incorrect, the processor must roll back the instructions it executed speculatively, alongside any state changes incurred by these instructions.
However, speculative execution leaves traces in the CPU's microarchitectural state, notably in the cache. Thus, a Spectre attacker might confuse the CPU's branch predictor into incorrectly executing instructions that should not have been executed otherwise. In case this incorrect speculation operates over private data, it is possible to leak the data via a side channel thus allowing attackers to read data otherwise inaccessible to them. In particular, in case a suitable Spectre-vulnerable code pattern (gadget) is present in a process belonging to a targeted program, an attacker might abuse this gadget in order to recover the contents of the process's entire address space and the data within it. Being a fundamental issue with speculative execution, Spectre is a threat to nearly all software, ranging from the computer's operating system to the web browser.
Operating systems such as Windows, Linux, and macOS currently isolate different programs into different units of execution called processes. The CPU then enforces this isolation at the hardware level, preveting one process from accessing the contents of other processes.
Strict Site Isolation is a recent browser architecture aimed at increasing browser security. Rather then arbitrarily assign different websites into different processes, browsers with Strict Site Isolation enabled ensure that content from different websites will be located in different processes. For example, data pertaining to google.com will never share the same process as the data for wikipedia.org, thus ensuring that these websites are isolated from each other at the hardware level.
eTLD+1 is an acronym for effective top-level domain plus one. A top-level domain (TLD) is the part of a domain name without dots, such as "com", "org", or "edu". Users can register domain names under a TLD, like "example.com". On the other hand, an effective top-level domain (eTLD) contains dots and is therefore not a true TLD, but is the part of a domain name under which subdomains can be registered directly. An example is "edu.au", with "adelaide.edu.au" registered under it.
The +1 refers to the term that comes just before the TLD or eTLD, delimited by a dot. That is, for "example.com" it is "example", and for "adelaide.edu.au" it is "adelaide". If two websites share a TLD or eTLD as well as the term preceding it, Chrome might consolidate them into the same process, despite Strict Site Isolation. Thus, Chrome will separate "example.com" and "example.net" due to different TLDs, and also "example.com" and "attacker.com" because the +1 terms (preceding the TLD) are different. However, "attacker.example.com" and "corporate.example.com" are allowed to share the same process due to their common eTLD+1 of "example.com". This allows pages hosted under "attacker.example.com" to potentially extract information from pages under "corporate.example.com".
Spectre is fundamentally a hardware vulnerability where footprints of speculative execution are not cleaned up completely within the processor's state. Thus, Strict Site Isolation cannot fix Spectre. Instead, Strict Site Isolation attempts to limit information leakage by separating the contents of different websites into different processes.
Since Spectre's original introduction in 2018, browser vendors have deployed many countermeasures in order to make Spectre harder to exploit. In addition to Strict Site Isolation, which prevets different webpages from sharing the same process, Chrome also partitions the address space of each process into different 32-bit sandboxes (despite being a 64-bit application). Limiting all values to be 32-bit prevents a Spectre attacker from crossing partition boundaries, thus further limiting information exposure.
We have tested Spook.js on Chromium, which is the basis of the Chrome browser. Thus, in addition to Chrome itself, we expect most Chromium-based browsers to be vulnerable to some variant of Spook.js. This includes recent versions of Microsoft's Edge browser, as well as Brave which is a privacy-centered browser.
In addition, sites can register their domain name to the Public Suffix List (PSL). The PSL is maintained by Mozilla, and is a list of domains under which users can register names directly (even if the domains are not true top-level domains). Chrome will not consolidate pages if their eTLD+1 domain is present in the PSL. That is, x.publicsuffix.com and y.publicsuffix.com will always be separated.
Finally, as a response to our work, Google introduced Strict Extension Isolation, a feature which prevents multiple extensions from being consolidated into the same process under memory pressure. This stops Spook.js (packaged as a malicious extension) from reading the memory of other extensions. Strict Extension Isolation is enabled as of Chrome versions 92 and up. We also link a blog post by Google's Chromium Project on tips for web developers to defend their sites against side channel attacks.
Our Spook.js logo contains the logo of the Chromium project, which is published under the Creative Commons Attribution 2.5 Generic (CC BY 2.5) license. We acknowledge that the Chromium logo belongs to the Chromium project, maintained by Google. While we have not modified the Chromium logo itself, we include it as a component of the Spook.js logo.
Accordingly, we release our logo under the same license. You can modify, redistribute, and copy it freely. Logo (excluding the Chromium logo component) designed by Jason Kim (who had to teach himself a bit of digital illustration just for it!)
This work was supported by the Air Force Office of Scientific Research (AFOSR) under award number FA9550-20-1-0425; an ARC Discovery Early Career Researcher Award (project number DE200101577); an ARC Discovery Project (project number DP210102670); CSIRO's Data61; the Defense Advanced Research Projects Agency (DARPA) and Air Force Research Laboratory (AFRL) under contracts FA8750-19-C-0531 and HR001120C0087; Israel Science Foundation grants 702/16 and 703/16; the National Science Foundation under grant CNS-1954712; Len Blavatnik and the Blavatnik Family foundation and Blavatnik ICRC at Tel-Aviv University; Robert Bosch Foundation; and gifts from Intel and AMD.