Hackers can force iOS and macOS browsers to divulge passwords and much more

 

Researchers have devised an attack that forces Apple’s Safari browser to divulge passwords, Gmail message content, and other secrets by exploiting a side channel vulnerability in the A- and M-series CPUs running modern iOS and macOS devices.

 

iLeakage, as the academic researchers have named the attack, is practical and requires minimal resources to carry out. It does, however, require extensive reverse-engineering of Apple hardware and significant expertise in exploiting a class of vulnerability known as a side channel, which leaks secrets based on clues left in electromagnetic emanations, data caches, or other manifestations of a targeted system. The side channel in this case is speculative execution, a performance enhancement feature found in modern CPUs that has formed the basis of a wide corpus of attacks in recent years. The nearly endless stream of exploit variants has left chip makers—primarily Intel and, to a lesser extent, AMD—scrambling to devise mitigations.

Exploiting WebKit on Apple silicon

The researchers implement iLeakage as a website. When visited by a vulnerable macOS or iOS device, the website uses JavaScript to surreptitiously open a separate website of the attacker’s choice and recover site content rendered in a pop-up window. The researchers have successfully leveraged iLeakage to recover YouTube viewing history, the content of a Gmail inbox—when a target is logged in—and a password as it’s being autofilled by a credential manager. Once visited, the iLeakage site requires about five minutes to profile the target machine and, on average, roughly another 30 seconds to extract a 512-bit secret, such as a 64-character string.

 

 

“We show how an attacker can induce Safari to render an arbitrary webpage, subsequently recovering sensitive information present within it using speculative execution,” the researchers wrote on an informational website. “In particular, we demonstrate how Safari allows a malicious webpage to recover secrets from popular high-value targets, such as Gmail inbox content. Finally, we demonstrate the recovery of passwords, in case these are autofilled by credential managers.”

 

 

While iLeakage works against Macs only when running Safari, iPhones and iPads can be attacked when running any browser because they’re all based on Apple’s WebKit browser engine. An Apple representative said iLeakage advances the company’s understanding and that the company is aware of the vulnerability and plans to address it in an upcoming software release. There is no CVE designation to track the vulnerability.

 

Unique WebKit attributes are one crucial ingredient in the attack. The design of A-series and M-series silicon—the first generation of Apple-designed CPUs for iOS and macOS devices respectively—is the other. Both chips contain defenses meant to protect against speculative execution attacks. Weaknesses in the way those protections are implemented ultimately allowed iLeakage to prevail over them.

Speculative execution: The hack that keeps on hacking

In early 2018, two research teams working independently of each other unveiled two attacks, one known as Spectre and the other as Meltdown. Both were able to recover confidential information by exploring a newly discovered side channel in a performance-enhancing feature known as speculative execution, which is built into virtually all modern CPUs. Moving data from main system memory to a CPU is time consuming. To reduce wait times, modern CPUs execute instructions as soon as the required data becomes available rather than in a sequential order.

 

A key ingredient in this out-of-order paradigm is predicting paths the CPU is likely to go down. When the prediction turns out to be correct, the task is completed faster than it would have been otherwise. When it's not, the CPU will abandon the mispredicted path and follow a new, correct path. While CPUs can reverse most of the effects, the Spectre and Meltdown researchers discovered that certain artifacts at a microarchitectural level, including cache and predictor states, couldn’t be restored. The insight allowed the researchers to devise attacks that tricked Intel and AMD CPUs into mispredicting sensitive instructions that spilled secrets from one app into a separate, unrelated app, a serious breach of a core security boundary.

 

In the years since, CPU and software makers have come up with a host of methods to mitigate speculative execution attacks. A key mitigation has been to limit the ability of a browser or other app from being able to measure the precise time a CPU takes to perform a certain operation. In browsers, more mitigations come in the form of defenses known as compressed 35-bit addressing and value poisoning.

 

 

iLeakage represents several breakthroughs. First is its ability to defeat these defenses with Safari running on A- and M-series chips by exploiting a type confusion vulnerability. Secondly, it's a variant that doesn’t rely on timing but rather on what’s known as a race condition. A third key ingredient is the unique ability of WebKit to consolidate websites from different domains into the same renderer process using the common JavaScript method window.open.

 

An overview of how the race condition-based gadget runs to distinguish cache hits from cache misses.

 

On their informational site, the researchers wrote:

 

In order to construct iLeakage, we first reverse engineer the cache topology on Apple Silicon CPUs. We then overcome Apple's timer limitations using a new speculation-based gadget, which allows us to distinguish individual cache hits from cache misses, despite having access to only low resolution timers. We also demonstrate a variant of this gadget that uses no timers, leveraging race conditions instead. After using our speculation-based gadget to construct eviction sets, we proceeded to analyze Safari's side channel resilience. Here, we bypass Safari's 35-bit addressing and the value poisoning countermeasures, creating a primitive that can speculatively read and leak any 64-bit pointer within Safari's rendering process. Combining this with a new method for consolidating websites from different domains into the same address space, we are able to mount a speculative type confusion attack that leaks sensitive information.

In an accompanying research paper (PDF), the researchers describe the timerless variant this way:

 

We combine all of our above-constructed primitives into a timerless Spectre v1 gadget Proof of Concept (PoC). At a high level, we achieve this by replacing the cache timing-based method of leaking secrets under speculation with our gadget for timerlessly distinguishing cache misses from cache hits. Here, we show that our attacks have near perfect accuracy across Safari, Firefox, and Tor.

Putting it all together

For the attack to work, a vulnerable computer must first visit the iLeakage website. For attacks involving YouTube, Gmail, or any other specific Web property, a user should be logged into their account at the same time the attack site is open. And as noted earlier, the attacker website needs to spend about five minutes probing the visiting device. Then, using the window.open JavaScript method, iLeakage can cause the browser to open any other site and begin siphoning certain data at anywhere from 24 to 34 bits per second.

 

As the research paper explains:

 

We begin by recalling that while Safari generally follows a strict process-per-tab model, pages opened by the window.open function share a rendering process with the parent page. Thus, we created an attacker page that binds window.open to an onmouseover event listener, allowing us to open any webpage in our address space whenever the target has their mouse cursor on the page. We note that even if the target closes the opened page, the contents in memory are not scrubbed immediately, allowing our attack to continue disclosing secrets. Finally, as window.open performs consolidation regardless of the origins of both the parent and opened webpages, we host our attacker’s page on a non-publicly accessible webserver, while using window.open to consolidate pages from other domains.

 

It's likely that many targets would recognize the iLeakage-spawned pop-up window and close it. The attack will work even then because the contents remain intact in memory, allowing iLeakage to continue disclosing secrets.

 

The types of data that can be recovered include:

 

Passwords autofilled by credential managers

 

iLeakage Demo 1: Attacking Instagram and LastPass.

 

Gmail inbox content

 

iLeakage Demo 2: Gmail Inbox on Mobile Safari.

 

YouTube watch history

 

Leakage Demo 3: YouTube Watch History on iOS Chrome.

 

iLeakage is a practical attack that requires only minimal physical resources to carry out. The biggest challenge—and it’s considerable—is the high caliber of technical expertise required. An attacker needs to not only have years of experience exploiting speculative execution vulnerabilities in general but also have fully reverse-engineered A- and M-series chips to gain insights into the side channel they contain. There’s no indication that this vulnerability has ever been discovered before, let alone actively exploited in the wild.

 

That means the chances of this vulnerability being used in real-world attacks anytime soon are slim, if not next to zero. It’s likely that Apple’s scheduled fix will be in place long before an iLeakage-style attack site does become viable.

 

Listing image by iLeakage