Live data from Hacker News

New speculative attacks on Apple CPUs

predictors.fail

121–130 of 365 posts

Re: New speculative attacks on Apple CPUs

#121
post #92

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.

One spot where safari is in an advantageous position to force a new default, as long as they roll it out on iOS first.

Re: New speculative attacks on Apple CPUs

#122
post #23

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

It's a tragedy that so many websites insist on having the ability to run random downloaded code on our systems to do basic things like displaying simple text and images. Things browsers are capable of with nothing but HTML. Google refuses to even show search results, a bunch of literal hyperlinks, without javascript being enabled.

Re: New speculative attacks on Apple CPUs

#123

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

Announce what to whom? To the hundreds of millions of users out there that don't even know what a browser is, let alone why it's now talking to them about something called a "site isolation framework"?

Re: New speculative attacks on Apple CPUs

#124
post #58
post #34

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

It's not unreasonable to set a different header value for the login page only, where it should be safe because no external user data is being rendered.

Re: New speculative attacks on Apple CPUs

#125
post #92

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

Good luck trying to get Google or Microsoft to throw their paying enterprise users under the bus in the interest of slightly safer sandboxing defaults.

Re: New speculative attacks on Apple CPUs

#126

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

As someone who followed a course on all of this, this is indeed how we started out.

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

[1] https://www.vusec.net/projects/glitch/

Re: New speculative attacks on Apple CPUs

#127
post #56
post #14

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

GLitch was a Rowhammer browser based attack [1]. It's not Spectre/Meltdown but still, for a while people thought it couldn't be done.

[1] https://www.vusec.net/projects/glitch/

Re: New speculative attacks on Apple CPUs

#128
post #58
post #34

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

Sites can also opt into the same behavior by setting the rel="noopener" or alternatively target="_blank" attributes on outgoing links (i.e. tags).

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

#129

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

It is probably outside the scope of what one company can do (although Apple is quite large…). But we need to fix our understanding of backwards compatibility. If a computer system provides the ability to keep doing something, but the way it provides that capability requires it to be insecure, then the system should not really be thought of as “backward compatible.” Because reasonably prudent people can’t actually keep doing the thing they were doing before.

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

#130

The 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?

It's a recent trend basically since Heartbleed had a cool name and lots of press. Why would you not want your exploit to be well known and to get lots of credit for it? If anything it's surprising it didn't happen earlier.
Post reply on HN