Hacker News Reader

Hacker News

Comment by jeroenhd | Hacker News Reader

Full thread

jeroenhd

Things I'm missing from this FAQ:

- Is this a Webkit vulnerability or a Safari vulnerability?

- Does enabling Lockdown mode mitigate this vulnerability, seeing as mobile Safari doesn't expose these dev settings?

- What's the timeline on the disclosure to Apple?

Edit: they updated the page to answer the last question:

  When did you notify Apple?

  We disclosed our results to Apple on September 12, 2022 (408 days before public release).

View on HN

> Is this a Webkit vulnerability or a Safari vulnerability?

This is technically a Hacker News Favorite Processor a.k.a. M1/M2 vulnerability. However all relevant CPUs on the market now has the same vulnerabilities so it became a feature so software has to be designed to mitigate it.

It is impractical to get rid of all possible Spectre gadgets from WebKit, so the browser should be designed to leverage OS's Spectre mitigation to deal with these vulnerabilities (i.e. isolate different websites in different processes).

And, in the FAQ:

> Ultimately, we achieve a out-of-bounds read anywhere in the address space of Safari's rendering process.

So, in my opinion, this is a Safari vulnerability: they hold Site Isolation wrong.

>> Ultimately, we achieve a out-of-bounds read anywhere in the address space of Safari's rendering process.

> So, in my opinion, this is a Safari vulnerability: they hold Site Isolation wrong.

Previously, something I would normally consider a Safari specific bug (IndexedDB storage not being isolated to its owning web page) also made it into Gnome Web and various other WebKit browsers. Site Isolation is enabled on other browsers but as an outsider I have no idea if that is normally handled by WebKit or by the surrounding framework.

It looks like Gnome Web/Epiphany is safe at least: https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/448 but there are plenty of WebKit implementations out there, such as cars and video game consoles.

The merge request you linked is for cross-site navigation, which is a different feature flag than the cross-site window open recommended by this paper.

Hmm, unfortunate. It was tagged as "site isolation" in https://gitlab.gnome.org/GNOME/epiphany/-/blob/master/NEWS?r... so I thought it was the same feature.

This is a WebKit vulnerability in the face of surprising microarchitectural behavior. For one, they put a website into the address space of another, which is a bug under Spectre. Second, some of their code is correct under a traditional model but does not take speculative attacks into account, and needs to be updated.

I'm not familiar with WebKit, but I consider Site Isolation a Chromium feature instead of a Blink one. Is it supposed to be solved within the render engine?

Yes, typically the web engine will handle process isolation. While there are exceptions the API for these typically look more like "open a website for me in this window" and not "please spin up my GPU process for this tab".

>However all relevant CPUs on the market now has the same vulnerabilities so it became a feature so software has to be designed to mitigate it.

I don't understand what you mean when you say the vulnerabilies to speculative exucution side channel attacks is a CPU "feature." Could you expound on your meaning there?

In my mind, a CPU feature would be something like out-of-order execution or integrated memory controllers. Isn't this more of a side effect (or an "oh shit..."). For example, I'd consider speculative execution to be a feature of CPUs with a side effect causing these vulnerabilities to side channel attacks, much like weight loss is a feature of the medicine Xenical (orlistat) with a side effect causing anal leakage.

Also, mitigations for newly discovered spectre-like attacks have to be done software side, but successive processor generations will bake those mitigations into the silicon to reduce the performance penalties associated with software fixes.

> mitigations for newly discovered spectre-like attacks have to be done software side, but successive processor generations will bake those mitigations into the silicon to reduce the performance penalties associated with software fixes.

This is not correct. Spectre-like bug in the same privilege domain (as to the CPU) is just unfixable. Meltdown, L1TF etc were fixed in hardware because they leak data across hardware enforced privilege domains (i.e. userspace/kernel/enclave), in this sense it is a hardware bug.

In case of browser, the CPU feature is "CPU is eager to leak arbitrary data in the same address space even if on the face the code does not seem to do it". This can't be fixed in the hardware because it's not a hardware bug: there's no hardware implemented security boundary, it's purely software defined.

They have an answer to your last question in the FAQ

  When did you notify Apple?
  We disclosed our results to Apple on September 12, 2022 (408 days before public release).

They added this FAQ point a couple minutes ago, that's why the existing comments didn't see it.

That wasn't on the page when I read it.

Good that they've added it. Disappointing to see that Apple has gone so long without releasing a fix.

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

I don’t know why they make it an Apple problem. They claim their attack works on all browsers, and it doesn’t look like it’s fixed on any of them.

It only affects Apple processors. From the FAQ:

Yes (with a very high chance), if you have a device running macOS or iOS with Apple's A-series or M-series CPUs. This includes all recent iPhones and iPads, as well as Apple's laptops and desktops from 2020 and onwards.

The only reason why attack works on all browsers is because Apple force all browsers on their platform to use Webkit. This is why it's Apple problem.

That’s only true for the iOS related platforms. Nice old MacOS still lets you run any browser you want, including one you’ve developed yourself if you so wish.

It works on webkit. Firefox isn't affected on MacOS, but it is on iOS because apple forces the use of webkit there.

This appears to be an architectural vulnerability where a speculative execution side channel similar to Spectre can be utilized within Safari or any other browser. The specifics of which environment is exploitable comes down to the specifics of the JavaScript-based gadget they use to trigger/measure this side channel. It may be in the linked paper which I haven’t read yet.

These questions are answered in the FAQ now:

> - Is this a Webkit vulnerability or a Safari vulnerability?

Safari.

"...iLeakage exploits idiosyncrasies in Safari's JavaScript engine..."

> - Does enabling Lockdown mode mitigate this vulnerability, seeing as mobile Safari doesn't expose these dev settings?

Yes.

"Lockdown Mode does mitigate our work by disabling just-in-time (JIT) compilation in Safari, which is a performance feature used by iLeakage to build its attack primitives."

That's good to know. Glad WebKit isn't inherently broken.

Reply on news.ycombinator.com