We present iLeakage, a transient execution side channel targeting the Safari web browser present on Macs, iPads and iPhones. iLeakage shows that the Spectre attack is still relevant and exploitable, even after nearly 6 years of effort to mitigate it since its discovery. We show how an attacker can induce Safari to render an arbitrary webpage, subsequently recovering sensitive information present within it using speculative execution. In particular, we demonstrate how Safari allows a malicious webpage to recover secrets from popular high-value targets, such as Gmail inbox content. Finally, we demonstrate the recovery of passwords, in case these are autofilled by credential managers.
We show a scenario where the target uses an autofilling credential manager (LastPass in this demo) to sign into Instagram with Safari on macOS.
Assuming the target is signed into Google on Safari for iOS, we recover the subject lines of the Gmail account's most recent messages on an iPad.
We recover YouTube watch history from the Chrome browser for iOS, which is a shell on top of Safari's browsing engine due to Apple's App Store policy.
On a MacBook Pro with the new Apple M3 chip and the latest macOS 14.1.1 and Safari 17.1, we first recover the target's Facebook password. Subsequently, we recover the two-factor authentication (2FA) token through Google Messages when it is sent over SMS to an Android phone.
At the time of public release, Apple has implemented a mitigation for iLeakage in Safari. However, this mitigation is not enabled by default, and enabling it is possible only on macOS. Furthermore, it is marked as unstable. We will keep this FAQ updated as Apple pushes more iOS and macOS updates. If you wish to enable the mitigation on your Mac now, below are the steps. Please note: this mitigation is compatible only with macOS Ventura 13.0 and higher.
First, the Terminal app needs full disk access:
If you have updated to macOS Sonoma 14.0 or higher:
defaults write com.apple.Safari IncludeInternalDebugMenu 1.
If you are on an earlier macOS version (macOS Ventura 13.0 to 13.6):
.pkgfile extension, and follow its directions until Safari Technology Preview is installed.
defaults write com.apple.SafariTechnologyPreview IncludeInternalDebugMenu 1.
This enables Safari's hidden debugging menu. Then, follow these steps:
Afterwards, you're all set! To disable the mitigation, repeat steps 1-4 from above, and the checkmark will disappear. To disable the hidden debugging menu, open the Terminal app, copy and paste the following command (depending on your OS version), and press the Return key to run. The changes will apply the next time you start Safari (or Safari Technology Preview).
defaults write com.apple.Safari IncludeInternalDebugMenu 0
defaults write com.apple.SafariTechnologyPreview IncludeInternalDebugMenu 0
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.
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).
This research was supported by
the Air Force Office of Scientific Research (AFOSR) under award number FA9550-20-1-0425;
an ARC Discovery Project number DP210102670;
the Defense Advanced Research Projects Agency (DARPA) under contract HR00112390029 and
the Deutsche Forschungsgemeinschaft (DFG, German Research Foundation) under Germany's Excellence
Strategy - EXC 2092 CASA - 390781972;
the National Science Foundation under grant CNS-1954712;
and gifts by Cisco and Qualcomm.
The views and conclusions contained in this website are those of the authors and should not be interpreted as representing the official policies, either expressed or implied, of the U.S. Government.
Parts of this work were undertaken while Yuval Yarom was affiliated with the University of Adelaide.