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

281–290 of 365 posts

Re: New speculative attacks on Apple CPUs

#281

Post by saagarjha »

MagicMoonlight wrote: post #280
dailykoder wrote: post #278

Earlier quoted context omitted.

Maybe the boomers were right and we made computers way too complex? This might be a bit of a hyperbole, but seems like there will always be a security hole (even if mostly hard to exploit). But I also guess we can't get much faster without it either. So maybe we should reduce complexity. Atleast for safety critical systems.

Now wait until the zoomers come along and take the lead on these products. They grew up with iPads and no file system. It’s going to be chaos!

Boomers grew up without a filesystem too and things seem to have worked out fine.

Re: New speculative attacks on Apple CPUs

#282

Post by omcnoe »

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

But how much data are those popup based auth sending through? At the absolute most a few MB in a couple calls. Even if it's dramatically slower over IPC it's not going to cause issues.

Re: New speculative attacks on Apple CPUs

#283

Post by plufz »

lxgr wrote: post #163
plufz wrote: post #142

Earlier quoted context omitted.

I would guess you would use a deprecation message in the console? Like they have done over cookie changes, etc. A normal user would obviously not check the console, but the devs or admins of the site sure might.

That's assuming there's still a dev around that has knowledge of, or even access to, the source code of a given webapp depending on the legacy functionality.

Sure. I just got a vibe from this thread that breaking security changes in the browser is a totally unknown phenomenon, but we had changes to behavior from other origin headers, demanding ssl and changes to cookies. Somehow we survived. ;)

Re: New speculative attacks on Apple CPUs

#284

Post by School-Cotton »

positr0n wrote: post #264
thijsr wrote: post #33

Earlier quoted context omitted.

It depends on your threat model. If you don't run any untrusted code on your hardware (including Javascript), you can safely disable the mitigations. If you do run untrusted code, keep them enabled.

What is the threat model if I run lots of untrusted JavaScript, but I only have a small amount of memory in other processes worth reading and I would notice sustained high CPU usage? Is there an example in the wild of a spectre exploit stealing my gmail cookie and doing something with it? (Would be difficult since it's tied to other fingerprints like my IP) Or stealing credit card numbers when they're in memory after…

If you’re not sure, just keep the mitigations on.

Re: New speculative attacks on Apple CPUs

#285

Post by AHTERIX5000 »

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?

If mitigations include disabling SMT and the workload is compiling code, then the difference is easily in double digits.

Re: New speculative attacks on Apple CPUs

#286

Post by School-Cotton »

phendrenad2 wrote: post #239

Seems like speculative execution is just fundamentally insecure. With SPECTRE/MELTDOWN mitigations, doesn't CPU performance drop below the same CPU performance with no branch prediction at all? Should we move back to CISC? Or maybe VLIW?

> SPECTRE/MELTDOWN mitigations, doesn't CPU performance drop below the same CPU performance with no branch prediction at all?

No. Processors with no branch prediction would be many times slower (up to dozens of times slower on workloads that don’t fit in cache)

Re: New speculative attacks on Apple CPUs

#287

Post by jabwd »

yard2010 wrote: post #273
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…

Safari is Internet Explorer of the 20'

This is a flawed comparison in many ways. As you might not understand IE was problematic because of its massive install base and everyone only, and only writing their websites for chrome oh wait. Typo'd there, meant IE.

Re: New speculative attacks on Apple CPUs

#288

Post by jabwd »

kd913 wrote: post #221
yoshicoder wrote: post #82

Funny that I am seeing this now, because last Fall I had Daniel Genkin as my Intro to Cyber Security Professor (co-author of this result). Interesting class, but I remember him mentioning that they were working on a speculative attack for Apple CPUs after seeing the results of spectre and meltdown on Intel CPUs. I remember how he seemed almost paranoid about security, and I suppose I see why now (security is almost n…

Am curious if the problem impacts m4 given it came out after this was released and disclosed. That and it moved to Arm’s 9.2 instructions.

Keep in mind that it takes at least 3 months to produce an M4, and the design has been finalized long before that. So most likely yes

Re: New speculative attacks on Apple CPUs

#289

Post by prmoustache »

hashstring wrote: post #223
prmoustache wrote: post #150

Earlier quoted context omitted.

Then don't use an iPhone until it is patched.

What about turn JS off on your favourite iOS browser?

That wouldn't prevent possible malware apps using WKWebview from getting out of the jail they are running out right?

Re: New speculative attacks on Apple CPUs

#290

Post by lazide »

leeter wrote: post #271
MikeHolman wrote: post #260

Earlier quoted context omitted.

I worked on a browser team when Spectre/Meltdown came out, and I can tell you that a big reason why Firefox and Chrome do such severe process isolation is exactly because these speculative attacks are almost impossible to entirely prevent. There were a number of other mitigations including hardening code emitted from C++ compilers and JS JITs, as well as attempts to limit high precision timers, but the browser vendor…

To add to this and to quote a friend who has more NDAs in regards to microarchitecture than I can count and thus shall remain nameless: "You can have a fast CPU or a secure CPU: Pick one". Pretty much everything a modern CPU does has side effects that are something that any sufficiently motivated attacker can find a way to use (most likely). While many are core specific (register rename, execution port usage for exam…

This is also a fundamental property - if you can save time in some code/execution paths, but not in others (which is a very desirable attribute in most algorithms!), and that algorithm is doing something where knowing if it was able to go faster or slower has security implications (most any crypto algorithm, unless very carefully designed), then this is just the way it is - and has to be.

The way this has been trending is that in modern systems, we try to move as much of the ‘critical’ security information processing to known-slower-but-secure processing units.

But, for servers, in virtualized environments, or when someone hasn’t done the work to make that doable - we have these attacks.

So, ‘specialization’ essentially.

Post reply on HN