Spook.js

If you have an Intel processor or an Apple device with the M1 chip, then yes with very high probability. We also expect our attack to be effective for AMD machines, however this has been only partially demonstrated.

Under certain conditions, malicious JavaScript code running in one Chrome browser tab can read the contents being displayed on another Chrome tab, which might contain sensitive information such as passwords, bank details, etc. Furthermore, malicious extensions might be able to read the contents of other extensions, including sensitive information stored inside them (e.g., passwords inside credential managers).

Anything stored in the memory of a website being rendered or a Chrome extension is fair game. In our evaluation, we have demonstrated leakage of the following information:

• The list of same-site tabs which a user currently has open
• Phone numbers, addresses, and bank account information displayed on a website
• Usernames, passwords, and credit card numbers autofilled by credential managers
• Under certain circumstances, images in Google Photos which a user is currently viewing
• Information sensitive to an individual Chrome extension, such as its login information

We do not have any evidence so far that Spook.js has been or not been abused in the wild.

It is highly unlikely, because the attack code runs in the browser and does not leave traces in traditional system log files.

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.

No, you can (and should!) continue using credential managers. While credential recovery is possible, it can only happen if the attacker has obtained a webpage on the domain associated with the credential. This limits the risk of credential theft, as most websites do not allow users to upload webpages arbitrarily. On balance, not using credential managers puts your passwords at much greater risk of being insecurly stored and subsequently stolen.

JavaScript is a programming language understood by web browsers, making it one of the core components of the web. It is used by interactive websites such as social media, e-commerce, and games. While JavaScript-based side channel attacks are harder to design and implement, they are much more dangerous as browsers execute JavaScript code automatically and without any user interaction. In particular, JavaScript-based attacks do not require the user to run any malicious software on their devices.

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.

However, there are certain conditions under which Chrome does not separate two websites. The most prominent is the case where two websites sharing an eTLD+1 domain are opened in separate tabs, while the system is already under memory pressure from other tabs being open. In our paper, we identified several services which host attacker-controlled JavaScript code on the same eTLD+1 domain as a page containing sensitive information, such as the service's login page. In this example, in case the user opens a page hosting Spook.js attack code in parallel to the service's login page, Chrome's Strict Site Isolation implementation consolidates these two pages into the same process. This then allows our attack to extract the user's credentials as these are being autofilled by the browser's credential manager.

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.

Spook.js shows that these countermeasures are insufficient in order to protect users from browser-based speculative execution attacks. More specifically, we show that Chrome's Strict Site Isolation implementation consolidates webpages based on their eTLD+1 domain, allowing an attacker-controlled page to extract sensitive information from pages on other subdomains. Next, we also show how to bypass Chrome's 32-bit sandboxing mechanism. We achieve this by using a type confusion attack, which temporarily forces Chrome's JavaScript execution engine to operate on an object of the wrong type. Using this method we can combine multiple 32-bit values into a single 64-bit pointer, which allows us to read the process's entire address space. Finally, going beyond initial proof-of-concepts, we demonstrate end-to-end attacks extracting sensitive information such as the list of open pages, their contents, and even login credentials.

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.

Other browsers like Firefox and Safari use very different JavaScript execution engines, which currently stops Spook.js from working. We leave the task of investigating speculative exection attacks on these browsers to future work. Finally, Firefox has recently introduced Strict Site Isolation in its stable release. While Spook.js does not work on Firefox as is, we note that similarly to Chrome, Firefox also consolidates pages based on their eTLD+1 domain.

Web developers can immediately separate untrusted, user-supplied JavaScript code from all other content for their website, hosting all user-supplied JavaScript code at a domain that has a different eTLD+1. This way, Strict Site Isolation will not consolidate attacker-supplied code with potentially sensitive data into the same process, putting the data out of reach even for Spook.js as it cannot cross process boundaries.

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.

Yes, there is an academic paper available here, also through the download button at the top of this webpage. It will appear at the 43rd IEEE Symposium on Security and Privacy (S&P'22) in May 2022.

Yes, please see our GitHub repository.

Our rationale for attacking Tumblr and LastPass simply arose from the fact that they are a widely used website and Chrome extension respectively, and are likely to contain sensitive information. As a disclaimer, we clarify that Spook.js exploits weaknesses in the Strict Site Isolation mechanism of the Chrome browser, and does not rely on vulnerabilities in either service. In particular, we do not discourage users from using these services.

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!)