Thursday, January 30, 2025

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.

omcnoe:

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.open in 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.

MikeHolman:

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.

Bill Toulas:

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:

Update (2025-01-31): Hector Martin (via Robin Kunde):

DIT fixes FLOP, and SSBS fixes SLAP. Those are documented, architecturally defined mechanisms to control this behavior. No chicken bits needed.

The CPUs are working as intended. Browsers just need to get their head out of the sand and flip those bits when running untrusted JS.

2 Comments RSS · Twitter · Mastodon


Does Safari always open sites in separate processes when manually opening a new tab (e.g., via Command+T or via another macOS app sending a link to be opened by Safari) instead of allowing a webpage in one tab to open a link in a new tab via window.open? If so, does that prevent the SLAP attack from working against the contents of those manually opened tabs? Wouldn't the best practice, then, be to (1) never login to a website (or access a site where you are already logged in) by clicking a link on another site, and (2) when browsing a site where you are logged in, never click a link to another website, but instead copy the link, manually open a new tab, and then paste the link into the address bar? Obviously, that's cumbersome and annoying, but if it mitigates SLAP, then maybe it's worth the effort.


It would make sense for these bits to be set by the OS by default: if the app accesses the internet, these bits are set, unless some entitlement is provided.

Leave a Comment