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

111–120 of 365 posts

Re: New speculative attacks on Apple CPUs

#111

Post by zamalek »

lxgr wrote: post #69
omcnoe wrote: post #63

Earlier quoted context omitted.

Cross-Origin-Opener-Policy seems like a case of bad defaults where a less secure option has been selected so that we don't break some poorly maintained websites. Better to get the actual users of `window.open` to fix their code than to make every website insecure out of the box. I can't imagine there are many sites passing significant amounts of data through this, the small number of users where IPC poses too high a…

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

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

Re: New speculative attacks on Apple CPUs

#112

Post by throwaway894345 »

lxgr wrote: post #92
dfedbeef wrote: post #91

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.

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

#113

Post by latexr »

sofixa wrote: post #13
phoe-krk wrote: post #8

Earlier quoted context omitted.

> We disclosed our results to Apple on May 24, 2024. Apple’s Product Security Team have acknowledged our report and proof-of-concept code, requesting an extended embargo beyond the 90-day window. At the time of writing, Apple did not share any schedule regarding mitigation plans concerning the results presented in this paper. The vulnerability is over half a year old and over a quarter over the embargo window.

I wonder if Apple are being slow due to the complexity of the potential fix, or because they're dragging their feet.

As someone who has reported several (software) security vulnerabilities to Apple, I couldn’t care less. Some of the things I reported are trivial to fix, and dealing with their team has been a frustrating experience. They don’t deserve extensions, they need to get their shit together and stop releasing new crap every year. Clearly they can’t do it properly.

Re: New speculative attacks on Apple CPUs

#115

Post by 9283409232 »

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?

Only academics read exploit papers. I don't see anything wrong with releasing the information is a more digestible way if it is something that affects the general populace. I only knew about heartbleed because of the website. https://heartbleed.com/

Re: New speculative attacks on Apple CPUs

#116

Post by caust1c »

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?

Blame society. Businesses won't value security unless the fear of getting attacked is sufficiently strong and the losses significant. Otherwise why invest in it at all?

Definitely not just hardware exploits though. Look at heartbleed for example. It's been going on a long time. Hardware exploits are just so much more widely applicable hence the interest to researchers.

Re: New speculative attacks on Apple CPUs

#117

Post by woodruffw »

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?

Heartbleed et al. demonstrated conclusively that recognition matters; I don't begrudge researchers any technique that increases the relative visibility of their work.

Re: New speculative attacks on Apple CPUs

#118

Post by ragnot »

goldsteinq wrote: post #99
omcnoe wrote: post #30

Earlier quoted context omitted.

Serious answer, don't use Safari. Use a browser that properly separates webpages into isolated processes so that this kind of cross-site read is not possible.

There’re no other browsers on iPhone. Every iPhone browser is a reskin of Safari. They’re in theory supposed to allow other browsers in the EU, but AFAIK it has not happened yet.

God I hate Apple sometimes

Re: New speculative attacks on Apple CPUs

#120

Post by lxgr »

wbl wrote: post #108
lxgr wrote: post #81

Earlier quoted context omitted.

> Unless you just mean for incredibly restrictive usages such as eBPF? I was actually thinking something more like a bytecode interpreter that runs one operation and then sleeps until the next full wall clock second, but yes, that's my point: If you don't care about performance, you can make process isolation safe very easily.

That is actually still not secure. The cache will happily retain the trace of the access forever.

Yeah, but unless a cache miss has a performance penalty of roughly one second, you should be fine.
Post reply on HN