MEET FLOP AND ITS CLOSE RELATIVE, SLAP Apple chips can be hacked to leak secrets from Gmail, iCloud, and more Side channel gives unauthenticated remote attackers access they should never have. Dan Goodin Jan 28, 2025 3:56 pm | 14 Apple is introducing three M3 performance tiers at the same time. Credit: Apple Apple is introducing three M3 performance tiers at the same time. Credit: Apple Story textSizeSmallStandardLargeWidth *StandardWideLinksStandardOrange* Subscribers only Learn moreApple-designed chips powering Macs, iPhones, and iPads contain two newly discovered vulnerabilities that leak credit card information, locations, and other sensitive data from the Chrome and Safari browsers as they visit sites such as iCloud Calendar, Google Maps, and Proton Mail.The vulnerabilities, affecting the CPUs in later generations of Apple A- and M-series chip sets, open them to side channel attacks, a class of exploit that infers secrets by measuring manifestations such as timing, sound, and power consumption. Both side channels are the result of the chips use of speculative execution, a performance optimization that improves speed by predicting the control flow the CPUs should take and following that path, rather than the instruction order in the program.A new directionThe Apple silicon affected takes speculative execution in new directions. Besides predicting control flow CPUs should take, it also predicts the data flow, such as which memory address to load from and what value will be returned from memory.The most powerful of the two side-channel attacks is named FLOP. It exploits a form of speculative execution implemented in the chips load value predictor (LVP), which predicts the contents of memory when theyre not immediately available. By inducing the LVP to forward values from malformed data, an attacker can read memory contents that would normally be off-limits. The attack can be leveraged to steal a targets location history from Google Maps, inbox content from Proton Mail, and events stored in iCloud Calendar.SLAP, meanwhile, abuses the load address predictor (LAP). Whereas LVP predicts the values of memory content, LAP predicts the memory locations where instructions data can be accessed. SLAP forces the LAP to predict the wrong memory addresses. Specifically, the value at an older load instruction's predicted address is forwarded to younger arbitrary instructions. When Safari has one tab open on a targeted website such as Gmail, and another open tab on an attacker site, the latter can access sensitive strings of JavaScript code of the former, making it possible to read email contents.There are hardware and software measures to ensure that two open webpages are isolated from each other, preventing one of them from (maliciously) reading the other's contents, the researchers wrote on an informational site describing the attacks and hosting the academic papers for each one. SLAP and FLOP break these protections, allowing attacker pages to read sensitive login-protected data from target webpages. In our work, we show that this data ranges from location history to credit card information.There are two reasons FLOP is more powerful than SLAP. The first is that it can read any memory address in the browser process's address space. Second, it works against both Safari and Chrome. SLAP, by contrast, is limited to reading strings belonging to another webpage that are allocated adjacently to the attacker's own strings. Further, it works only against Safari. The following Apple devices are affected by one or both of the attacks: All Mac laptops from 2022present (MacBook Air, MacBook Pro) All Mac desktops from 2023present (Mac Mini, iMac, Mac Studio, Mac Pro) All iPad Pro, Air, and Mini models from September 2021present (Pro 6th and 7th gen., Air 6th gen., Mini 6th gen.) All iPhones from September 2021present (All 13, 14, 15, and 16 models, SE 3rd gen.Attacking LVP with FLOPAfter reverse-engineering the LVP, which was introduced in the M3 and A17 generations, the researchers found that it behaved unexpectedly. When it sees the same data value being repeatedly returned from memory for the same load instruction, it will try to predict the loads outcome the next time the instruction is executed, even if the memory accessed by the load now contains a completely different value! the researchers explained. Therefore, using the LVP, we can trick the CPU into computing on incorrect data values. They continued: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.FLOP requires a target to be logged in to a site such as Gmail or iCloud in one tab and the attacker site in another for a duration of five to 10 minutes. When the target uses Safari, FLOP sends the browser training data in the form of JavaScript to determine the computations needed. With those computations in hand, the attacker can then run code reserved for one data structure on another data structure. The result is a means to read chosen 64-bit addresses.When a target moves the mouse pointer anywhere on the attacker webpage, FLOP opens the URL of the target page address in the same space allocated for the attacker site. To ensure that the data from the target site contains specific secrets of value to the attacker, FLOP relies on behavior in Apples WebKit browser engine that expands its heap at certain addresses and aligns memory addresses of data structures to multiples of 16 bytes. Overall, this reduces the entropy enough to brute-force guess 16-bit search spaces. Illustration of FLOP attack recovering data from Google Maps Timeline (Top), a Proton Mail inbox (Middle), and iCloud Calendar (Bottom). Credit: Kim et al. When a target browses with Chrome, FLOP targets internal data structures the browser uses to call WebAssembly functions. These structures first must vet the signature of each function. FLOP abuses the LVP in a way that allows the attacker to run functions with the wrong argumentfor instance, a memory pointer rather than an integer. The end result is a mechanism for reading chosen memory addresses.To enforce site isolation, Chrome allows two or more webpages to share address space only if their extended top-level domain and the prefix before this extension (for instance www.square.com) are identical. This restriction prevents one Chrome process from rendering URLs with attacker.square.com and target.square.com, or as attacker.org and target.org. Chrome further restricts roughly 15,000 domains included in the public suffix list from sharing address space.To bypass these rules, FLOP must meet three conditions:It cannot target any domain specified in the list such that attacker.site.tld can share an address space with target.site.tldThe webpage must allow users to host their own JavaScript and WebAssembly on the attacker.site.tld,The target.site.tld must render secretsHere, the researchers show how such an attack can steal credit card information stored on a user-created Square storefront such as storename.square.site. The attackers host malicious code on their own account located at attacker.square.site. When both are open, attacker.square.site inserts malicious JavaScript and WebAssembly into it. The researchers explained:This allows the attacker storefront to be co-rendered in Chrome with other store-front domains by calling window.open with their URLs, as demonstrated by prior work. One such domain is the customer accounts page, which shows the target users saved credit card information and address if they are authenticated into the target storefront. As such, we recover the pages data. Left: UI elements from Squares customer account page for a storefront. Right: Recovered last four credit card number digits, expiration date, and billing address via FLOP-Control. Credit: Kim et al. SLAPping LAP sillySLAP abuses the LAP feature found in newer Apple silicon to perform a similar data-theft attack. By forcing LAP to predict the wrong memory address, SLAP can perform attacker-chosen computations on data stored in separate Safari processes. The researchers demonstrate how an unprivileged remote attacker can then recover secrets stored in Gmail, Amazon, and Reddit when the target is authenticated. Top: Email subject and sender name shown as part of Gmails browser DOM. Bottom: Recovered strings from this page. Credit: Kim et al. Top Left: A listing for coffee pods from Amazons Buy Again page. Bottom Left: Recovered item name from Amazon. Top Right: A comment on a Reddit post. Bottom Right: the recovered text. Credit: Kim et al. "The LAP can issue loads to addresses that have never been accessed architecturally and transiently forward the values to younger instructions in an unprecedentedly large window" the researchers wrote. "We demonstrate that, despite their benefits to performance, LAPs open new attack surfaces that are exploitable in the real world by an adversary. That is, they allow broad out-of-bounds reads, disrupt control flow under speculation, disclose the ASLR slide, and even compromise the security of Safari."The researchers said that they suspect chips from other manufacturers also use LVP and LAP and may be vulnerable to similar attacks. They also said they don't know if browsers such as Firefox are affected because they weren't tested in the research.An academic report for FLOP is scheduled to appear at the 2025 USENIX Security Symposium. The SLAP research will be presented at the 2025 IEEE Symposium on Security and Privacy. The researchers behind both papers are: Jason Kim, Georgia Institute of Technology Jalen Chuang, Georgia Institute of Technology Daniel Genkin, Georgia Institute of Technology Yuval Yarom, Ruhr University BochumThe researchers published a list of mitigations they believe will address the vulnerabilities allowing both the FLOP and SLAP attacks. They said that Apple officials have indicated privately to them that they plan to release patches.In an email, an Apple representative declined to say if any such plans exist. We want to thank the researchers for their collaboration as this proof of concept advances our understanding of these types of threats," the spokesperson wrote. Based on our analysis, we do not believe this issue poses an immediate risk to our users.Dan GoodinSenior Security EditorDan GoodinSenior Security Editor Dan Goodin is Senior Security Editor at Ars Technica, where he oversees coverage of malware, computer espionage, botnets, hardware hacking, encryption, and passwords. In his spare time, he enjoys gardening, cooking, and following the independent music scene. Dan is based in San Francisco. Follow him at here on Mastodon and here on Bluesky. Contact him on Signal at DanArs.82. 14 Comments