SLAP, Apple, and FLOP: Safari, Chrome at risk of data theft on iPhone, Mac, iPad Silicon

Many recent Apple laptops, desktops, tablets, and phones powered by Cupertino's homegrown Silicon processors can be exploited to reveal email content, browsing behavior, and other sensitive data through two newly identified side-channel attacks on Chrome and Safari.

On Tuesday, security researchers Jason Kim, Jalen Chuang, and Daniel Genkin from the Georgia Institute of Technology in the US, and Yuval Yarom from Ruhr University Bochum in Germany, published papers describing two speculative-execution attacks dubbed SLAP [PDF] and FLOP [PDF].

These attacks exploit weaknesses in Apple's Arm-compatible processor designs to extract information from memory that should be off limits. In practice, that means a malicious webpage in one Chrome or Safari browser tab snooping on a page in another tab and stealing its sensitive information, such as emails being read and what have you.

SLAP and FLOP build on Spectre, the 2018 microarchitecture attack that abused CPU speculation, in which processors try to accelerate operations by predicting the flow of execution through program code. By speculatively computing possible branches in logic in advance and discarding paths that aren't needed, CPUs can run applications faster.

But the risk is that these speculative actions, even if discarded, can have observable side effects on shared resources – think caches or buffers – and it's these side effects that can be used by malware and rogue users to infer sensitive data, such as encryption keys, from programs and users that should be otherwise inaccessible.

Predictable

The SLAP attack targets Apple-designed processors, such as the M2, A15, and newer models that have a Load Address Predictor (LAP), which predicts the memory addresses of subsequent load instructions to optimize performance.

When the sequence of load instructions is deemed to be predictable (eg, the values are constant or striding), the LAP speculatively issues a load for the predicted address and waits for it to resolve – either continuing if it predicted correctly or flushing the pipeline and resuming operations if incorrect.

"We discover that if we train the LAP on striding memory addresses, the LAP will access the next sequence in the striding pattern and compute using the data in that address, even if the program never actually accesses it," the researchers explain, noting that this differs from prefetching, which does not speculative execute downstream instructions.

Building on this knowledge, they use a technique demonstrated in the previously disclosed iLeakage attack in which a webpage can force another webpage to be handled by the same process, as a way to bypass Safari's page isolation protections.

"We find that when this occurs, the two webpages also share internal memory allocation regions for data, such as strings," the boffins note. "In turn, this allows the adversary to jump the LAP to the target webpage's string and trick the CPU into operating on it, eventually leaking the string's content over a covert channel."

Essentially, SLAP provides a way for one webpage in a browser to load strings of data in another webpage that's open so the adversary can view the victim's information.

Among the demonstrations cited, the researchers showed how this technique can be used to target an authenticated Gmail user who visits the attacker's webpage.

"The attacker webpage allocates 1.7 MB of filler and training strings, and then calls window.open on Gmail’s inbox page when the mouse cursor is placed over itself," the authors explain. "As Gmail loads, JavaScript in the page starts rendering the inbox, whose content is personalized to the target. Over repeated trials, we show that the subject line and the sender’s identity can land in the reachable out-of-bounds region of the LAP, allowing for recovery by the adversary…"

Get a load of this

On the other hand, the FLOP attack targets a feature in more recent Apple CPUs (M3, M4, A17), the Load Value Prediction (LVP), which attempts to predict the values a memory load operation will return based on previously observed patterns. Already this sounds like a disaster.

"We found that if the LVP sees the same data value being repeatedly returned from the memory subsystem for the same load instruction, the LVP will attempt to guess the load's outcome the next time that load instruction executes, even if the memory accessed by the load now contains a completely different value!" the researchers explain. "Therefore, using the LVP, we can trick the CPU into computing on incorrect data values."

In the context of Apple's Safari browser, the researchers managed to train the LVP to read out-of-bounds memory through speculative type confusion. By making the CPU core transiently execute a gadget – a specific code structure resident in memory – on data of an unexpected type (eg, binary in lieu of a string), the CPU will read an attacker-chosen memory address and transmit the read data through a covert channel.

Using this technique, the researchers say they were able to obtain the target's location history from Google Maps, inbox content from ProtonMail, and iCloud Calendar events.

Asus lets processor security fix slip out early, AMD confirms patch in progress Spectre flaws continue to haunt Intel and AMD as researchers find fresh attack method Nearly every AMD CPU since 2017 vulnerable to Inception data-leak attacks Faulty instructions in Alibaba's T-Head C910 RISC-V CPUs blow away all security

Safari lacks Site Isolation, a feature available in Chrome that puts websites in different processes, so they can't affect one another. Nonetheless, Chrome's defenses aren't foolproof.

FLOP can be used against Google Chrome on Apple hardware, by running WebAssembly functions with the wrong arguments, which again allows arbitrary memory to be read through type confusion. But given that Chrome implements Site Isolation, attacking Chrome via FLOP means the attack code has to be on the same eTLD+1 (effective Top-Level Domain plus one) domain as the target domain.

The SLAP attack on an M2 CPU running macOS managed a median bitwise accuracy of 87.9 percent and a throughput of 0.384 bits per second. Tested on a MacBook Pro with M3 CPU and 8 GB of RAM, the FLOP attack achieved a median accuracy of 89.58 percent and a throughput of 0.492 bits per second. So these techniques require some patience to fetch anything longer than a strong password.

Videos of SLAP and FLOP variant attacks can be found on the researchers' website.

The following Apple hardware is said to be affected:

All Mac laptops from 2022-present (MacBook Air, MacBook Pro) All Mac desktops from 2023-present (Mac Mini, iMac, Mac Studio, Mac Pro) All iPad Pro, Air, and Mini models from September 2021-present (Pro 6th and 7th gen., Air 6th gen., Mini 6th gen.) All iPhones from September 2021-present (All 13, 14, 15, and 16 models, SE 3rd gen.)

The researchers have informed Apple of their findings, released proof-of-concept code, and suggested several mitigations. Chief among them is setting the Data Independent Timing (DIT) bit present in the Armv8.4-A ISA and newer. The DIT bit, they say, "disables the LVP on the M3 CPU on a per-process basis, with no privileges needed to set the bit."

Makers of web browsers are advised to set the DIT bit when executing user-supplied JavaScript or WebAssembly and when handling sensitive webpage operations, namely password fields. The cost of doing so on Safari imposed computational overhead that slowed the browser by about 4.5 percent on the Speedometer 3.0 benchmark test.

For the SLAP attack, mitigations involving various settings (eg, a system register bit that disables all out-of-order execution) that appear to degrade performance significantly and thus are not recommended. The researchers note that Apple has been working on implementing Site Isolation in WebKit, at the heart of Safari, which could help when completed.

Apple appears none too concerned about all this. "We want to thank the researchers for their collaboration as this proof of concept advances our understanding of these types of threats," a spokesperson told The Register. "Based on our analysis, we do not believe this issue poses an immediate risk to our users." ®