Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New speculative attacks on Apple CPUs

predictors.fail

Post reply on HN
Print view View original

191–200 of 365 posts

Re: New speculative attacks on Apple CPUs

#191

Post by sabas123 »

mettamage wrote: post #126
LPisGood wrote: post #80

Earlier quoted context omitted.

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/

Keep in mind that getting meltdown to work might be very difficult depending on your setup. I wouldn't have been able to at least when starting out my teacher didn't provide us with targetable hardware.

A spectre (particularly RSB-based ones) are nice to start out with imo.

Re: New speculative attacks on Apple CPUs

#192

Post by danans »

lxgr wrote: post #187
danans wrote: post #184

Earlier quoted context omitted.

> 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. From the FAQ: "For leaking secrets, both SLAP and FLOP are confined to the address space they are trained in. As pointed out by iLeakage, Safari lacks Site Isolation, a measure used to enforce that two different webpages not from the same domain can…

Yes, in some special cases , which both embedded/opened and embedding/opening websites can avoid by setting the appropriate HTTP headers/HTML attributes. Of course it would be better if Safari would do the same thing as Chrome and Firefox and just provide a separate process for all contexts, including those that can communicate per specifications. But there's something sites can do today to avoid this potential infor…

> websites can avoid by setting the appropriate HTTP headers/HTML attributes.

Individual sites plugging browser + CPU security holes seems like a violation of separation of concerns. Yes, I hope every bank out there puts this workaround into their site ASAP, but that's hardly a solution for the flaw itself.

Re: New speculative attacks on Apple CPUs

#193

Post by junon »

lxgr wrote: post #171
zamalek wrote: post #111

Earlier quoted context omitted.

We had the tech in the 80's for the browser to facilitate popup authentication with process isolation. It's this niche and esoteric tech called IPC[1], so niche that one really can't blame Apple for not hearing about it. It truly boggles the mind as to how all the other browsers pull it off. [1]: https://en.wikipedia.org/wiki/Inter-process_communication

To be fair, there wasn't that much sensitive web content around in the 80s to leak (primarily due to the web not yet existing, nor browsers), so it's only fair that browsers didn't consider using IPC for site isolation back then.

That, and "cyber security" wasn't really a formalized field. It arguably still isn't, depending on how the question's framed.

Re: New speculative attacks on Apple CPUs

#194

Post by junon »

lxgr wrote: post #185
zamalek wrote: post #182

Earlier quoted context omitted.

The point of my rather facetious comment is that IPC a well known thing (I struggle to even call it "tech") that has been around for 30-40 years. I don't understand why Apple needs people to make excuses for them, but this excuse would render Apple vastly more incompetent than neglecting to separate browser tabs in 2025.

Browsers are incredibly complex, and moving them to an IPC model is not easy. Essentially, you need to ensure "same process like", performant JavaScript interoperability in some cases, often (but not always) due to backwards compatibility. Firefox has shared a lot about their efforts in moving there. If you're curious, there are a lot of blog posts and internal design docs under their project name "Project Fission".…

We already have this with (iirc) postMessage API.

Re: New speculative attacks on Apple CPUs

#195

Post by Khaine »

amatecha wrote: post #186
kergonath wrote: post #158

Earlier quoted context omitted.

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

idunno, as a professional web dev since 1998, I don't understand why Google, Apple and Mozilla are trying so hard to make the web browser like a complete OS (I technically understand why, I just think it's ridiculous). The amount of obscure APIs being added just boosts the surface area for vulnerabilities and makes low-resource web browsing nearly impossible. You either get "a web browser that works" or "a web browse…

I agree with you, particularly when 90% of sites people visit are to read, watch, or engage with content.

Re: New speculative attacks on Apple CPUs

#196

Post by lxgr »

junon wrote: post #194
lxgr wrote: post #185

Earlier quoted context omitted.

Browsers are incredibly complex, and moving them to an IPC model is not easy. Essentially, you need to ensure "same process like", performant JavaScript interoperability in some cases, often (but not always) due to backwards compatibility. Firefox has shared a lot about their efforts in moving there. If you're curious, there are a lot of blog posts and internal design docs under their project name "Project Fission".…

We already have this with (iirc) postMessage API.

That API is exactly one of the reasons Safari still runs some distinct origin sites in the same process together.

Performantly implementing that API across processes is possible, but not quite trivial.

Re: New speculative attacks on Apple CPUs

#197

Post by wging »

lxgr wrote: post #128
wging wrote: post #58

Earlier quoted context omitted.

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.

That is a little different, though: those attributes are for if you're example.com linking to protonmail, the header is for if you're protonmail deciding on security policies for interactions with example.com.

Re: New speculative attacks on Apple CPUs

#198

Post by lxgr »

fweimer wrote: post #70
lxgr wrote: 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…

Would it help to use separate processes and share the data on demand only, via IPC with a robust speculation barrier?

Yes, and that’s what Firefox and Chrome are already doing.

Re: New speculative attacks on Apple CPUs

#199

Post by hajile »

porcoda wrote: post #155
artisanspam wrote: post #114

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,…

Getting funding and good job offers is mostly about marketing. Even worse, lots of people controlling the purse strings aren't domain experts. In a way, it's no different from getting published in specific high-profile publications or attending specific universities.

Re: New speculative attacks on Apple CPUs

#200

Post by spydum »

ribcage wrote: post #160
autoexec wrote: post #122

Earlier quoted context omitted.

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.

I got bad news: those systems were NOT secure
Post reply on HN