The affected Apple devices are the following:

• 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.)

There are hardware and software measures to ensure that two open webpages are isolated from each other, preventing one of them form (maliciously) reading the other's contents. 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.

While FLOP has an actionable mitigation, implementing it requires patches from software vendors and cannot be done by users. Apple has communicated to us that they plan to address these issues in an upcoming security update, hence it is important to enable automatic updates and ensure that your devices are running the latest operating system and applications.

We have not yet observed load address prediction or load value prediction in other processor vendors' products, such as Intel, AMD, Qualcomm, or Ampere.

We do not know. Our work focuses on Apple CPUs, and we have only tested our experiments on Apple CPUs.

We do not know, as we have not tested other browsers such as Firefox.

Since SLAP and FLOP are microarchitecture-based attacks, they do not leave any traces in the system's log files. While cached copies of previously visited websites may be present in the web browser, it is difficult to automatically detect malicious code patterns that exploit hardware vulnerabilities.

So far, we do not have any evidence that either SLAP or FLOP has been used in the wild.

We disclosed SLAP to Apple on May 24, 2024, and FLOP on September 3, 2024.

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's hardware to attack it, even if the software 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 SLAP and FLOP, comes from the CPU's microarchitecture. Whenever an attacker and target run on the physical 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 the control flow the CPU should take (such as branches and returns), 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. Nearly all 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.

In SLAP and FLOP, we demonstrate that recent Apple CPUs go beyond this, not only predicting the control flow the CPU should take, but also the data flow the CPU should operate on if data are not readily available from the memory subsystem. Unlike Spectre, mispredictions on data flow do not directly result in the CPU speculatively executing the wrong instructions. Instead, they result in the CPU executing arbitrary instructions on the wrong data. However, we show this can be combined with indirection techniques to execute wrong instructions.

To orchestrate SLAP, we begin by reverse engineering Apple's implementation of Load Address Prediction (LAP). We discover that if we train the LAP on striding memory addresses, the LAP will access address the next sequence in the striding pattern and compute using the data in that address, even if the program never actually accesses it. Here, we note that this is different from hardware prefetching. While prefetchers may bring the data inside the predicted addresses, they do not speculatively execute downstream instructions based on the prediction.

Next, we find an attack surface in Safari. Previously, iLeakage demonstrated a corner case in Safari's isolation scheme where an adversary's webpage can coerce an arbitrary target webpage to be handled by the same process. We find that when this occurs, the two webpages also share internal memory allocation regions for data, such as strings. 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.

Similarly to SLAP, we reverse engineer the Load Value Prediction (LVP) mechanism in Apple CPUs. 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! Therefore, using the LVP, we can trick the CPU into computing on incorrect data values.

We first demonstrate the dangers stemming from LVP in Safari, whose JavaScript engine first vets the type information of JavaScript data structures before determining the appropriate computations to run on them. If we train the LVP on the load instruction that retrieves this type information, we can cause code that is only supposed to run for one data structure on another data structure, causing speculative type confusion, and obtaining a read primitive to arbitrary 64-bit addresses.

Next, we move to Chrome, where internal table data structures for calling WebAssembly functions also vet the signature of each function before calling them with arguments. Here, we show that the LVP allows us to run a function with the wrong arguments (e.g., pointer instead of integer), again resulting in a type confusion based primitive for reading arbitrary memory addresses.

SLAP exploits a phenomenon in Safari where strings that belong to different webpages can be allocated within a close distance to each other, and thus discloses cross-origin strings that are allocated in proximity to the adversary's own strings. On the other hand, FLOP is a speculative type confusion attack that causes the CPU to bypass integrity checks on data structures, resulting in memory read primitives from arbitrary addresses in Safari and Chrome.

Furthermore, the underlying CPU microarchitecture that SLAP and FLOP exploit are also different. SLAP uses the Load Address Predictor (LAP), while FLOP uses the Load Value Predictor (LVP). As suggested by their names, the LAP predicts addresses while the LVP predicts values. Consider the following statement: "The CPU accesses memory at address 0xdeadbeef, which contains the value 0x1234." The next time the CPU performs a memory access, the LAP predicts the next address, i.e., what 0xdeadbeef will change to. Meanwhile, the LVP predicts the next value returned from memory, that is, what 0x1234 will change to. Going deeper in detail, we observe their internal structures are also different. For instance, the LAP requires a longer training sequence than the LVP to activate reliably, but only the LAP can observe strides and generate predictions accordingly.

JavaScript and WebAssembly are two programming languages that make up the backbone of interactive webpages, such as online games and video streaming services. JavaScript can update the content of the website directly, while WebAssembly is used for high-performance web applications. Ultimately, WebAssembly interfaces with JavaScript to deliver dynamic content to users. Since both are sandboxed in a browser environment, side-channel attacks are notably more difficult to implement in these languages. However, the impact is drastically greater, as browsers execute both types of code automatically and do not require the user to download the malicious program.

For leaking secrets, both SLAP and FLOP are confined to the address space they are trained in. As pointed out by iLeakage, Safari lacks Site Isolation, a measure used to enforce that two different webpages not from the same domain can never be handled by the same process. Thus, in Safari it is possible for an adversary's webpage to be handled by the same process (and thus address space) with an arbitrary webpage, increasing the attack surface including LAP- and LVP-based exploits.

On the other hand, although Chrome is equipped with Site Isolation, we demonstrate that it is not a perfect mitigation. We show the real-world existence of corner cases, where two subdomains of the same site can be merged into one process, again leading to LAP- and LVP-based attacks.

Yes, with rights waived via CC0. You can right-click each logo, which should list an option to save the image as a file.

The 'Read the Paper' buttons at the top of this website link to academic papers for SLAP and FLOP. SLAP will appear at the 2025 IEEE Symposium on Security and Privacy, and FLOP will appear at the 2025 USENIX Security Symposium.

You can find reverse-engineering experiment code and proof-of-concepts for SLAP at https://github.com/slap-flop/slap-artifacts and for FLOP at https://zenodo.org/records/14680908.