SLAP and FLOP Side-Channel Attacks
Jason Kim et al. (Hacker News, MacRumors, Slashdot):
We present SLAP, a new speculative execution attack that arises from optimizing data dependencies, as opposed to control flow dependencies. More specifically, we show that Apple CPUs starting with the M2/A15 are equipped with a Load Address Predictor (LAP), which improves performance by guessing the next memory address the CPU will retrieve data from based on prior memory access patterns.
However, if the LAP guesses wrong, it causes the CPU to perform arbitrary computations on out-of-bounds data, which should never have been accessed to begin with, under speculative execution. Building on this observation, we demonstrate the real-world security risks of the LAP via an end-to-end attack on the Safari web browser where an unprivileged remote adversary can recover email content and browsing behavior.
[…]
We present FLOP, another speculative execution attack that results from recent Apple CPUs predicting the outcome of data dependencies. Here, we demonstrate that Apple's M3/A17 generation and newer CPUs are equipped with a Load Value Predictor (LVP). The LVP improves performance on data dependencies by guessing the data value that will be returned by the memory subsystem on the next access by the CPU core, before the value is actually available.
If the LVP guesses wrong, the CPU can perform arbitrary computations on incorrect data under speculative execution. This can cause critical checks in program logic for memory safety to be bypassed, opening attack surfaces for leaking secrets stored in memory. We demonstrate the LVP's dangers by orchestrating these attacks on both the Safari and Chrome web browsers in the form of arbitrary memory read primitives, recovering location history, calendar events, and credit card information.
Their SLAP demo provides a great example of how defence-in-depth can make/break the viability of an exploit. That terrifying Safari demo is possible because Safari fails to isolate new windows in individual processes when calling
window.openin js.All the other side channel magic presented here doesn’t matter if the data you want to read is in a seperate process with sufficient separation from the “hostile” process in the address space.
I worked on a browser team when Spectre/Meltdown came out, and I can tell you that a big reason why Firefox and Chrome do such severe process isolation is exactly because these speculative attacks are almost impossible to entirely prevent. There were a number of other mitigations including hardening code emitted from C++ compilers and JS JITs, as well as attempts to limit high precision timers, but the browser vendors largely agreed that the only strong defense was complete process isolation.
Of course, third-party iOS browsers are not allowed to innovate on security, except possibly in the EU.
Apple acknowledged the shared proof-of-concept and stated it plans to address the issues. However, at the time of writing, the flaws remain unmitigated.
Previously:
- SysBumps Attack
- DMA Compliance: Alternative Browser Engines
- iLeakage: Browser-Based Timerless Speculative Execution Attacks on Apple Devices
- PACMAN Attack on M1 Processor
- Apple Silicon “Augury” DMP Vulnerability
- The Time to Fix Web Security Bugs
- M1racles: M1ssing Register Access Controls Leak EL0 State
- Microarchitectural Data Sampling (MDS) Mitigation
- Mitigating Spectre With Site Isolation in Chrome
- Intel CPU Design Flaw Necessitates Kernel Page Table Isolation
