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

201–210 of 365 posts

Re: New speculative attacks on Apple CPUs

#201

Post by ddtaylor »

cluckindan wrote: post #175
omcnoe wrote: post #18

Their SLAP demo provides a great example of how defence-in-depth can make/break the viability of an exploit. That terrifying Safari demo is possible because Safari fails to isolate new windows in individual processes when calling `window.open` in js. All the other side channel magic presented here doesn't matter if the data you want to read is in a seperate process with sufficient separation from the "hostile" proces…

In Safari settings under Advanced, it’s possible to enable ”verify window.open user gesture”. Does that help at all?

AFAIK this only means the attacker has to dupe you into doing a UI event like scrolling or clicking or touching something on page. Very easy to do.

Re: New speculative attacks on Apple CPUs

#202

Post by nicce »

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?

In this case it is very generic domain name. Maybe more specific one would be okay, but this is not anymore.

Re: New speculative attacks on Apple CPUs

#203

Post by nicce »

caust1c wrote: post #116
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.

It also feels like that people who are highly determined to build high quality, secure software are not valued that much.

It is difficult to prove their effort. One security-related bug removes everything, even if it happened only once in 10 years in 1 million line code base.

Re: New speculative attacks on Apple CPUs

#204

Post by Gigachad »

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.

Unix systems protected against a physical person trying to read or modify another persons file. They did not stop programs run by the user reading the users own data unexpectedly which is now considered unacceptable but was previously the norm.

Re: New speculative attacks on Apple CPUs

#205

Post by talldayo »

bawolff wrote: post #83
kevingadd wrote: post #79

Earlier quoted context omitted.

Multithreading may be an obscure feature to you but runtime developers get requests for it all the time. SAB becoming widely available was definitely delayed.

I would still maintain that needing multithreading on a website is relatively rare, and specifically needing SharedArrayBuffer instead of just multiple proceses (e.g. webworkers) is even more rare. Did use cases exist? Sure. But not sufficiently to move the needle on app store usage.

> Did use cases exist? Sure. But not sufficiently to move the needle on app store usage.

We can't say that for sure. There is no shortage of examples where Apple neglects a feature that might provide parity with their own services to avoid competition. Safari, being a mandatory feature of iOS, is reasonably implicated as part of the conspiracy to prevent users from buying and selling software without the assent of a corporate benefactor.

Re: New speculative attacks on Apple CPUs

#206

Post by avianlyric »

anyfoo wrote: post #145
ijustlovemath wrote: post #143

Earlier quoted context omitted.

wait, so does this mean that if an exploit tries to use a 32 bit address it's immediately shut down?

There are usually no valid 32 bit addresses, i.e. the first 4GB are not mapped.

That might be their point. As the OP quoted

> any virtual address below 0x100, 000, 000 is invalid.

That kinda suggests that all 32bit addresses are inherently invalid on 64bit MacOS

Re: New speculative attacks on Apple CPUs

#208

Post by umvi »

kllrnohj wrote: post #39
umvi wrote: 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?

What are you doing where you see anything remotely close to double-digit-% gains from disabling spectre mitigations?

my specific use case where I see significant performance improvement is image segmentation pipelines (which involve opencv-style image processing and AI inference). YMMV depending on your CPU I suppose.

Re: New speculative attacks on Apple CPUs

#209

Post by umvi »

paulddraper wrote: post #60
umvi wrote: 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?

> double-digit-% In the early days there was a ~10% hit, but that's changed a lot since then.

It depends on the CPU, think. The most dramatic improvement I've seen is 20-30%+ improvements in python run times for numpy/pytorch heavy workloads on c2-standard-16 VMs in GCP with spectre mitigations disabled

Re: New speculative attacks on Apple CPUs

#210

Post by lxgr »

wging wrote: post #197
lxgr wrote: post #128

Earlier quoted context omitted.

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.

The header works in both directions; cf. the table on https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cr....
Post reply on HN