iLeakage: The New Attack Lets Hackers Steal All Emails & Passwords On Apple Devices

I recently saw that researchers published a report on iLeakage, an advanced attack on Apple devices.

These are some of the insights I found interesting.

The iLeakage attack is a type of cyber attack that targets Apple devices, specifically the Safari browser. It uses a method called speculative execution to sneak into the system and steal sensitive information like passwords and emails. The attack is hard to detect because it doesn’t rely on timing measurements, making it a significant threat to Apple’s security.

Apple’s transition to its own ARM-based silicon in recent years has sparked interest in the security of these new chips. Recently, a group of researchers uncovered a new side-channel attack dubbed iLeakage that specifically targets Apple devices. In this post, I’ll provide an in-depth analysis of how iLeakage works and its implications.

Understanding iLeakage:

iLeakage is a speculative execution attack that leverages race conditions and timerless techniques to steal sensitive information from Apple devices running Safari. Specifically, it exploits the speculative execution mechanisms in Apple’s M-series CPUs to extract data from Safari on both Macs and iOS devices.

Some examples of what iLeakage can leak:

• Passwords stored in a user’s Gmail inbox
• Contents of private messages and texts
• Browsing history and activity on websites
• Logins and credentials autofilled by password managers
• Exact geolocation based on IP address

The key aspects of iLeakage are:

• Timerless and architecture-agnostic techniques — Most side channel attacks rely on precise timers to measure microarchitectural events. iLeakage replaces timing-based methods with race conditions to distinguish cache hits from misses without any timer. This makes the attack stealthier and cross-platform.
• Bypassing browser-based defenses — Browsers like Safari have degraded timer resolution and restricted APIs like SharedArrayBuffer to deter attacks. But iLeakage works despite these restrictions by using race conditions rather than timing data.
• Type confusion to read arbitrary memory — The attack confuses the CPU into speculatively accessing memory outside JavaScript’s sandbox. Specifically, it tricks the CPU into treating an object as a string to dereference a 64-bit pointer, circumventing Safari’s 35-bit addressing.
• Consolidating pages from different sites — iLeakage uses window.open to render target pages in the attacker’s process space. This bypasses Safari’s process isolation policies for cross-site windows.
• Evicting object’s type but not data — The attack carefully evicts parts of objects from cache to delay type checks but keep data cached for the exploit. This requires analysis of Safari’s memory allocator.
• Speculative suppression to avoid exceptions — Additional speculation hides type errors from Safari to prevent sandbox escapes from being detected. This ensures the attack can reliably read memory multiple times.

By chaining these techniques, iLeakage provides an extremely stealthy way to violate process isolation and leak arbitrary data from Safari on both macOS and iOS.

Technical Details of the Attack

Now, let’s do a deeper dive into some of the key technical innovations within iLeakage:

Timerless Cache Distinguishing Using Race Conditions

Since iLeakage cannot use timers, it instead builds a timerless primitive to distinguish cache hits from misses using race conditions.

Here’s how it works at a high level:

It launches two threads — a “reference” thread and the main thread.

The reference thread always executes the same data-dependent code and writes to a shared variable at the end.

The main thread runs the cache hit/miss test and calls plru.traverse(). This amplifies miss latencies.

If plru.traverse() takes longer due to a cache miss, the main thread will finish after the reference thread writes the shared variable. If it’s a cache hit, the main thread will finish first.

By reading the value of the shared variable, the main thread can infer if a cache miss occurred based on which thread won the race.

This approach removes the need for any timer since the order of operations indicates the cache state.

Quite an ingenious technique if you ask me!

Analyzing WebKit’s Memory Allocator

Another vital aspect of iLeakage is carefully analyzing WebKit’s memory allocator. This allows the attack to evict specific parts of an object’s memory while keeping other parts cached.

For example, the attack evicts the “type” of an object from the L2 cache but keeps the object’s data in L1 cache. This delays type checks during speculation but allows the object’s data to be used.

To achieve this, the researchers inspected how WebKit organizes memory for JavaScript objects like strings. They discovered certain built-in objects have “split” allocators placing the type on a separate cache line from the data.

By targeting these objects and constructing eviction sets, iLeakage can selectively evict the type but retain the rest in cache. Masterful cache analysis!

Speculative Suppression

An additional key technique in iLeakage is speculative suppression. This hides architectural type mismatch events from Safari using yet another layer of speculation.

Essentially, speculative suppression prevents Safari from detecting and blocking the type confusion occurring during the exploit. Even though the code triggers type errors architecturally, these are suppressed speculatively.

This reliable hides all evidence of the attack from Safari, allowing the CPU to continue speculating past type checks and leaking arbitrary data. Sneaky!

The researchers demonstrated many of these data leaks end-to-end. For instance, they showed an attacker page opening Gmail via window.open() and reading the target’s emails. They also accessed Android messages by opening a linked Google Messages window.

Even scarier, the team was able to trigger autofilled passwords from LastPass for sites like Google, Amazon, and GitHub. This highlights the extent of data vulnerable to iLeakage in real-world attack scenarios.

Since Safari is the only permitted browser engine on iOS, iLeakage threatens a massive number of iPhones and iPads. Any iOS device running Safari is susceptible. And the techniques apply to both macOS and iOS devices using Apple’s M-series chips.

Considering Safari’s ubiquity, this is a major vulnerability granting access to enormous amounts of sensitive user data. iLeakage demonstrates potential weaknesses in Apple’s isolation mechanisms that merit further research. Kudos to the team who uncovered this powerful attack!

Mitigations and Countermeasures

Of course, several mitigations have been proposed to protect against iLeakage:

• Improved site isolation in Safari to block cross-site window consolidation.
• Preventing speculation past type checks via hardware barriers.
• Removing unsafe optimizations that allow unpoisoned pointers.
• Serving COOP headers to make webpages cross-origin isolated.
• Keeping object type and data on same cache line during allocation.

During responsible disclosure, Apple implemented the first mitigation, modifying Safari to use stronger site isolation for window.open pages. This prevents the attack by isolating pages in separate processes.

Many mitigations boil down to reinforcing isolation mechanisms under speculation that are sometimes relaxed for performance. This demonstrates the balance required between security and efficiency.

The attack also shows that transient execution attacks are still evolving and finding new angles of attack. Hardware-backed security domains remain at risk due to the creativity of attackers.

There’s surely more research needed to understand these threats and how to mitigate them in browsers and beyond. The team behind iLeakage has made an impactful contribution to that effort!

Conclusion

So iLeakage is an intriguing new side-channel attack that bypasses multiple layers of defenses on Apple devices. By combining timerless techniques, type confusion, cache eviction strategies, and speculative suppression, it achieves a stealthy method for leaking arbitrary memory from Safari.

The attack has serious real-world implications, allowing attackers to steal highly sensitive user data. It also highlights weaknesses in Apple’s isolation mechanisms when faced with cunning transient execution techniques.

Kudos to the researchers for their in-depth methodology and analysis. iLeakage advances the state of side channel attacks and delivers important lessons for building secure systems resilient to speculative execution.

It’s an impactful contribution that reminds us clever attackers are always finding new ways to exploit hardware-level vulnerabilities.