Son of Spectre: No fix for iOS, unstable workaround in macOS.

Researchers found a nasty data leakage bug in all Apple’s ARM-based silicon. Both the A and M series chips suffer from the new side-channel vulnerability, which is similar to Spectre.

Incredibly, Apple’s known about “iLeakage” for more than a year, but has patched neither iOS nor macOS. In today’s SB Blogwatch, we run for the hills.

Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: Halloween party visuals.

Genkin and Friends Ride Again

What’s the craic? Dan Goodin broke the story—“Hackers can force iOS and macOS browsers to divulge passwords”:

“iLeakage represents several breakthroughs”
The attack is practical and requires minimal resources to carry out. [It’s] a class of vulnerability known as a side channel, [which] 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. … There is no CVE designation.
…
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. … The designs of A-series and M-series silicon … contain defenses meant to protect against speculative execution attacks. Weaknesses in the way those protections are implemented ultimately allowed iLeakage to prevail.
…
In the years since, CPU and software makers have come up with a host of methods to mitigate speculative execution attacks. … iLeakage represents several breakthroughs. First is its ability to defeat these defenses … by exploiting a type confusion vulnerability [in Safari].

Sounds complicated. Nick Farrell simplifies somewhat—“Boffins declare open season on Apple Safari”:

“Requires minimal resources”
It’s easy. … Apple’s Safari browser is a doddle to knock over. … This is highly amusing because the A- and M-series CPUs are being touted as a cure for cancer by the Tame Apple Press with all sorts of bizarre performance claims made for them.
…
Dubbed iLeakage, the attack requires minimal resources, although you need to know a bit about Apple hardware. … The researchers have successfully used iLeakage to recover YouTube viewing history, the content of a Gmail inbox … and a password.

Horse’s mouth? Jason Kim, Stephan van Schaik, Daniel Genkin and Yuval Yarom—“Timerless Speculative Execution Attacks”:

“September 12, 2022”
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. … 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 proceded 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.
…
Code running in one web browser tab should be isolated and not be able to infer anything about other tabs that a user has open. However, with iLeakage, malicious JavaScript and WebAssembly can read the content of a target webpage when a target visits and clicks on an attacker’s webpage.
…
We disclosed our results to Apple on September 12, 2022 (408 days before public release). … Apple has implemented a mitigation for iLeakage in Safari. However, this mitigation is not enabled by default, and enabling it is possible only on macOS, [via] Safari’s hidden debugging menu. … Furthermore, it is marked as unstable.

Wait. WHAT? mgiampapa double takes:

408 days and it still requires a user to enable via a debug menu? This is not a good security look from Apple.

Yeah, what else is waiting to bite us in Safari/WebKit? darlox sounds uneasy:

The hardware side-channel is obviously the big vector here, but given that process isolation has been a key security consideration of browsers for awhile, the fact that WebKit groups sites from window.open() into the same process is possibly the bigger sin. That’s something that is easily triggered by any website, and there’s probably other undiscovered vulnerabilities lurking somewhere else in that process.

Time to stop using Safari/WebKit? bill_mcgonigle spots the flaw in that argument:

Just switch to a browser using a different rendering engine on iOS until it’s patched? Oh.

Even if you could, it might not help. mccr8 explains:

Chromium and Firefox have implemented site isolation on their desktop browsers. So, pages that are not same site should never be loaded in the same process.
…
[But] on mobile browsers, Chromium’s site isolation is limited, and Firefox has not finished implementing it.

But back to the hardware vulnerability: Speculation considered harmful? Here’s habilain:

Speculative execution is not inherently insecure, but historically it hasn’t been designed with security in mind. Further, a lot of the ways which you could make it more secure cause a performance hit, which kind-of defeats the point.

Meanwhile, billybob2001 puns it up:

That name, though—”iLeakage.” Makes me WANNACRY.

And Finally:

In which Noah “Polyphonic” Lefevre says “cool” a lot

Click here for the extended, silent version

Previously in And Finally

You have been reading SB Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi, @richij or [email protected]. Ask your doctor before reading. Your mileage may vary. Past performance is no guarantee of future results. Do not stare into laser with remaining eye. E&OE. 30.

Image sauce: StorresJayrMx (via Unsplash; leveled and cropped)