> 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.
>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.
>> 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.
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.
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".
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.