Earlier quoted context omitted.
It's super feasible if you own the API default.
It's definitely a quick way to get all your users to switch to a different browser or figure out how to disable updates forever.
New speculative attacks on Apple CPUs
121–130 of 365 posts
Re: New speculative attacks on Apple CPUs
#122Earlier quoted context omitted.
Is it bad that I disable spectre mitigations on all my PCs to get a free double-digit-% performance boost?
If your machine is air gapped and/or not running random downloaded code, I think it is a possible reasonable option.
Re: New speculative attacks on Apple CPUs
#123Earlier quoted context omitted.
It's super feasible if you own the API default.
You just announce you are making a change and then turn it on later.
Re: New speculative attacks on Apple CPUs
#124Earlier quoted context omitted.
That's not a failure of Safari, it's required by window.open API semantics, in particular by the default Cross-Origin-Opener-Policy of "unsafe-none" [1]. By setting a different policy, sites can protect themselves against this. I guess technically browsers could open new windows in a new browsing context group regardless of this setting and relay the allowed types of messages via IPC (if any), but that would be a maj…
So should Protonmail (and any other site with similarly sensitive data) be setting that header, then? It’s probably hard to change the default. I bet some use cases (SSO popups?) depend on it.
Re: New speculative attacks on Apple CPUs
#125Earlier quoted context omitted.
It's definitely a quick way to get all your users to switch to a different browser or figure out how to disable updates forever.
I mean, if all major browsers do it roughly once then users will complain to the few broken websites. They won’t even think to blame the browser if every other site works fine and the broken site is broken on all browsers.
Re: New speculative attacks on Apple CPUs
#126For any yung'uns seeing this for the first time, the spectre and meltdown attacks (and accompanying papers) are worth reading. https://spectreattack.com/
I’d highly recommend reading Flush+Reload first since the cache side channel is key to any of these miceoarchitectural attacks.
1. Read Flush + Reload
2. Then reproduce it in C
3. Then read Meltdown
4. Reproduce it in C
5. Read Spectre
6. Reproduce it in C
After that we had to implement a VUSEC paper. I chose GLitch [1].
Re: New speculative attacks on Apple CPUs
#127Earlier quoted context omitted.
Hm... as I read it this is much worse. Spectre/Meltdown were data isolation vulnerabilities. You could exploit side channel (mostly timing) information to intuit state about memory across a protection boundary. Basically you can prime the CPU state to allow you to tell which of multiple code paths the kernel/hypervisor/whatever took, and then go from there to reading arbitrary data. Which is bad, obviously. Here, the…
A browser-based attack, in theory, could have happened with Spectre/Meltdown as well. I seem to recall a PoC for Spectre in the browser, actually. I believe it's also a reason that microsecond precision in the browser was made a bit more opaque since that era.
Re: New speculative attacks on Apple CPUs
#128Earlier quoted context omitted.
That's not a failure of Safari, it's required by window.open API semantics, in particular by the default Cross-Origin-Opener-Policy of "unsafe-none" [1]. By setting a different policy, sites can protect themselves against this. I guess technically browsers could open new windows in a new browsing context group regardless of this setting and relay the allowed types of messages via IPC (if any), but that would be a maj…
So should Protonmail (and any other site with similarly sensitive data) be setting that header, then? It’s probably hard to change the default. I bet some use cases (SSO popups?) depend on it.
And yes, something like a webmail site should definitely be setting the header, or at lest these attributes for outbound content links.
Re: New speculative attacks on Apple CPUs
#129Earlier quoted context omitted.
You just announce you are making a change and then turn it on later.
After building enterprise APIs for a few years, you’d be amazed at how hard it is to get companies to make even minor changes; backwards compatibility is key. Often it’s because they _can’t_ make the change themselves since they outsourced the code to a consulting agency. So they’d have to sign a new contract and get an agency to make the change. They just won’t, and you’ll have a browser that people stop using.
Of source, modern computers on the modern web don’t really provide the ability to do much at all in a reasonably prudent fashion, so it is all a bit moot I guess.
Re: New speculative attacks on Apple CPUs
#130The marketing culture for announcing hardware exploits is so strange to me. The norm seems to be getting a custom domain, logos, demos, an FAQ... why do all this instead of just reporting the exploit and releasing a paper?