iLeakage: Browser-based Timerless Speculative Execution Attacks on Apple Devices

Yes (with a very high chance), if you have a device running macOS or iOS with Apple's A-series or M-series CPUs. This includes all recent iPhones and iPads, as well as Apple's laptops and desktops from 2020 and onwards.

Code running in one web browser tab should be isolated and not be able to infer anything about other tabs that a user has open. However, with iLeakage, malicious JavaScript and WebAssembly can read the content of a target webpage when a target visits and clicks on an attacker's webpage. This content includes personal information, passwords, or credit card information.

iLeakage is mitigated as of Safari 17.2, which ships with iOS 17.2 and macOS 14.2. Hence, the mitigation would be to update your Apple devices to the latest OS version.

Lockdown Mode does mitigate our work by disabling just-in-time (JIT) compilation in Safari, which is a performance feature used by iLeakage to build its attack primitives. However, Lockdown Mode changes device behavior in other aspects. For example, some message attachments and unknown FaceTime calls may be blocked. See Apple's documentation for a complete list.

Furthermore, since iLeakage is written in JavaScript, disabling it also mitigates our work. However, disabling JavaScript may cause Safari to render some websites incorrectly or incompletely, and some advanced web features such as online payments may not work.

iLeakage is highly unlikely to be detected, since the attack runs in Safari and does not leave traces in the system's log files. However, traces of an attacker webpage hosting iLeakage may be present in the browser's cache of pages it has recently visited.

So far, we do not have evidence that iLeakage has been or not been abused. However, we note that iLeakage is a significantly difficult attack to orchestrate end-to-end, and requires advanced knowledge of browser-based side-channel attacks and Safari's implementation.

Not for the most part. In fact, we encourage using credential managers as opposed to trying to remember all of your passwords. In general, this is a better approach than reusing passwords or storing them insecurely. While iLeakage can recover credentials that are autofilled into a webpage, we note that many platforms require user interaction for autofill to occur.

We disclosed our results to Apple on September 12, 2022 (408 days before public release).

JavaScript and WebAssembly are two programming languages that make up the backbone of interactive webpages, such as online games and video streaming services. JavaScript can update the content of the website directly, while WebAssembly is used for high-performance web applications. Ultimately, WebAssembly interfaces with JavaScript to deliver dynamic content to users. Since both are sandboxed in a browser environment, side-channel attacks are notably more difficult to implement in these languages. However, the impact is drastically greater, as browsers execute both types of code automatically and do not require the user to download the malicious program.

Most computer bugs arise from mistakes in programming, such as missing bounds checks or use-after-frees. However, a side-channel attack exploits the implementation of a computer system to attack it, even if the program it runs is a secure algorithm. Systems can leak sensitive data through sound, electromagnetic radiation, or thermal throttling, just for a few examples.

Many side channels, including ones we use for iLeakage, comes from the CPU's microarchitecture. Whenever an attacker and target run on the same CPU, they share the CPU's internal resources such as cores, caches, and internal buffers. Sharing resources leads to contention, and contention can be measured indirectly through several variables like timing or power consumption. These measurements leave fingerprints on the target's behavior on the CPU. Accordingly, an attacker can abuse this to make inferences about the target's secrets even if they are isolated at the process level or the hypervisor level.

Virtually all modern CPUs use a performance optimization where they predict if a branch instruction will be taken or not, should the outcome not be readily available. Once a prediction is made, the CPU will execute instructions along the prediction, a process called speculative execution. If the CPU realizes it had mispredicted, it must revert all changes in the state it performed after the prediction. Both desktop and mobile CPUs exhibit this behavior, regardless of manufacturer (such as Apple, AMD, or Intel).

Spectre is a hardware vulnerability in virtually all modern CPUs that occurs when speculative execution backfires. While the CPU should ideally revert all changes in state, speculative execution leaves traces in the CPU's microarchitectural state and especially the cache. A Spectre attack coerces the CPU into speculatively executing the wrong flow of instructions. If this wrong flow has instructions depending on sensitive data, their value can be inferred through a side channel even after the CPU realizes the mistake and reverts its changes. An adversary can abuse this behavior to read data that they cannot normally access through program semantics. Because speculative execution is an important part of CPU performance that is infeasible to simply remove as a countermeasure, Spectre continues to be dangerous to software even years after its discovery.

Since the original Spectre exploit, browser vendors had significantly hardened browsers against attacks based on speculative and transient execution. For the case of Safari, this includes 35-bit addressing and the value poisoning, one process per tab isolation policy, as well as a low resolution timer.

Nonetheless, iLeakage is the first demonstration of a speculative execution attack against Apple Silicon CPUs and the Safari browser. In particular, we show that speculative execution attacks are possible on Apple's latest A-series and M-series architectures, despite Apple's side channel hardening. More specifically, we first devise an empirical method to recover the cache organization of Apple CPUs, since it is not publicly documented. We then use this information to develop a gadget that can distinguish cache hits from misses even in the absence of a cycle-accurate timer, which is the case for both native and browser environments for Apple devices. We use this gadget as both a test to generate cache eviction sets and as a covert channel. Finally, we migrate these techniques to the Safari browser, where we make Safari run code designed for one datatype on our maliciously crafted object of the wrong type while the CPU is performing speculative execution. Ultimately, we achieve a out-of-bounds read anywhere in the address space of Safari's rendering process.

In order to construct iLeakage, we first reverse engineer the cache topology on Apple Silicon CPUs. We then overcome Apple's timer limitations using a new speculation-based gadget, which allows us to distinguish individual cache hits from cache misses, despite having access to only low resolution timers. We also demonstrate a variant of this gadget that uses no timers, leveraging race conditions instead. After using our speculation-based gadget to construct eviction sets, we proceded to analyze Safari's side channel resilience. Here, we bypass Safari's 35-bit addressing and the value poisoning countermeasures, creating a primitive that can speculatively read and leak any 64-bit pointer within Safari's rendering process. Combining this with a new method for consolidating websites from different domains into the same address space, we are able to mount a speculative type confusion attack that leaks sensitive information.

The download button at the top of this website links to an academic paper, also available through this link. Our paper will appear at the 2023 ACM Conference on Computer and Communications Security (CCS).

On macOS, other popular browsers such as Chrome, Firefox and Microsoft Edge use different JavaScript engines. Since iLeakage exploits idiosyncrasies in Safari's JavaScript engine, these nuances suffice to deter iLeakage from working on them.

However, iOS has a different situation. Due to Apple's App Store and sandboxing policies, other browser apps are forced to use Safari's JavaScript engine. That is, Chrome, Firefox and Edge on iOS are simply wrappers on top of Safari that provide auxiliary features such as synchronizing bookmarks and settings. Consequently, nearly every browser application listed on the App Store is vulnerable to iLeakage.

Yes, we have SVG and PNG versions of the iLeakage logo. While the logo contains a modified version of the Safari logo, we note the Safari logo is in the public domain at Wikimedia Commons. Furthermore, it is not on Apple's list of trademarks.