Live data from Hacker News

New speculative attacks on Apple CPUs

predictors.fail

151–160 of 365 posts

Re: New speculative attacks on Apple CPUs

#151

Earlier quoted context omitted.

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.

[deleted]

Re: New speculative attacks on Apple CPUs

#152
post #69

Earlier quoted context omitted.

Forcing every website to adapt to a browser update is completely infeasible. > I can't imagine there are many sites passing significant amounts of data through this This is actually a quite common mechanism for popup-based authentication (which is much more secure than iframe-based one, as users can verify where they're potentially entering their credentials).

Why not a choice? Individuals could choose a "secure" browser or browser mode that provides increased protection from such attacks or a "compatible" one that is less likely to break old websites.

That’s not a real choice though. All it takes is one website that is essential to me not supporting the secure mode and I’m forced to opt-out. The upstream website is making the choice for me.

Re: New speculative attacks on Apple CPUs

#154
I'd really be curious to recreate this or to know if any of their results included using private browsing mode?

I only bring it up because one of the reasons I use Safari with private browsing as a default is because, if I were to login to a site like Facebook in one tab, open a new private tab in the same window and try going to Facebook, it would not recognize that I had already logged in from the other tab. Chrome nor Firefox do that.

Re: New speculative attacks on Apple CPUs

#155

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 happening in other parts of the research world too: a couple colleagues of mine were talking recently about a paper we found at a conference last year that had a web page to go along with it with a domain and fancy graphics and such. For a boring programming languages paper. We concluded this is the modern way to try to jack your citations by getting noticed for everything but the technical content of the work, which is a bit off putting.

Re: New speculative attacks on Apple CPUs

#156

Apple released minor-version updates to both macOS and iOS the past few days, both containing several security fixes. Has anyone been able to confirm if they address these exploits?

They haven’t yet. From https://www.bleepingcomputer.com/news/security/new-apple-cpu...:

Apple acknowledged the shared proof-of-concept and stated it plans to address the issues. However, at the time of writing, the flaws remain unmitigated.

"We want to thank the researchers for their collaboration as this proof of concept advances our understanding of these types of threats," Apple told BleepingComputer.

"Based on our analysis, we do not believe this issue poses an immediate risk to our users."

Re: New speculative attacks on Apple CPUs

#157

Earlier quoted context omitted.

You're not getting a boost, you're avoiding a penalty. In some (but not all) cases you can avoid the penalty and the exploits by disabling SMT. Remember, SMT isn't twice as many cores, just twice as many half-cores. You'll be fine.

In my experience SMT is still faster for most workloads even with the mitigations.

It's a common misunderstanding that the CPU suddenly has twice as large performance envelope when SMT is enabled. Only specialized software/scenarios will tangibly benefit from the parasitic gains of SMT-induced extra parallelization, e.g. video encoders like x264 or CPU-bound raytracers to name a few examples. These gains typically amount to about 15-20% at the very extreme end. In some cases you'll see a performance drop due to the inherent contention of two "cores" sharing one actual core. If you're stuck with a dual-core CPU for your desktop setup you should absolutely enable SMT to make your general experience feel a bit more responsive.

Re: New speculative attacks on Apple CPUs

#158
post #69

Earlier quoted context omitted.

Forcing every website to adapt to a browser update is completely infeasible. > I can't imagine there are many sites passing significant amounts of data through this This is actually a quite common mechanism for popup-based authentication (which is much more secure than iframe-based one, as users can verify where they're potentially entering their credentials).

Why not a choice? Individuals could choose a "secure" browser or browser mode that provides increased protection from such attacks or a "compatible" one that is less likely to break old websites.

> Individuals could choose a "secure" browser or browser mode that provides increased protection from such attacks or a "compatible" one that is less likely to break old websites.

And then we get thousands of posts whining about Safari being broken because it is "not like Chrome" and developers moaning that their unsafe pet API is not supported. Web developers are never going to play ball.

Re: New speculative attacks on Apple CPUs

#159
post #96
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…

Other browsers do site isolation, why can’t Safari? (:

Safari definitely does use site isolation (if you check "Activity Monitor", you'll find Safari processes named after the sites they're displaying) in almost all cases.

window.open, in some constellations, is an exception, because the opening and opened sites have an explicit communication facility available to them, unless at least one of the two explicitly opts out of it. As far as I'm aware, Safari also correctly implements that opt-out.

The only thing that Chrome and Firefox seem to be doing on top of that, as far as I understand, is to actually enforce process-per-site even for sites from the same "browsing context group" (i.e. all that can hold programmatic references to each other, e.g. via window.opener), which requires using IPC.

Re: New speculative attacks on Apple CPUs

#160

Earlier quoted context omitted.

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.

The real tragedy is that our processors try to win a bit more speed by sacrificing simplicity and therefore increasing the chances of such exploits. The other tragedy is that our operating systems are obsolete and have worthless security. Back in the day when UNIX was relevant, a hundred people could use it at the same on a mainframe with no fear of it breaking, now one person cannot safely use a single computer.
Post reply on HN