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

331–340 of 365 posts

Re: New speculative attacks on Apple CPUs

#331

Post by raxxorraxor »

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

Similar problem with third-party-cookies. They would make some auth cases easier and safer, but we shouldn't generally allow them because they are abused for tracking.

Here I would agree with you though.

Re: New speculative attacks on Apple CPUs

#332

Post by remram »

trompetenaccoun wrote: post #325
layer8 wrote: post #156

Earlier quoted context omitted.

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

It's crazy that they were informed about this months ago and still have not fixed it yet. They're going to have to now that it's public but why would that pressure even be needed. I naively assumed if Apple still gets one thing right it's security updates. This is disappointing and concerning.

Have you considered that it might be difficult?

Re: New speculative attacks on Apple CPUs

#333

Post by lxgr »

brookst wrote: post #317
fsflover wrote: post #294

Earlier quoted context omitted.

> I'm not surprised to see this come back to bite them if after like 7 years Apple still hasn't adopted the only strong defense. So the Apple's argument that iOS can't have alternative browsers for security is a lie.

Strange claim. Security isn’t a one-bit thing where you’re either perfectly secure or not. If someone breaks into your house through a window and steals your stuff, that does not make it a lie to claim that locking your front door is more secure. In any event, Apple’s claim isn’t entirely true. It’s also not entirely false. Browsers absolutely require JIT to be remotely performant. Giving third parties JIT on iOS wou…

> Giving third parties JIT on iOS would decrease security.

Well, at least in this case it would have greatly increased security (since it would have allowed the availability of actual, native Chrome and Firefox ports).

And otherwise: Does Apple really have zero trust in their OS in satisfying the basic functionality of isolating processes against each other? This has been a feature of OSes since the first moon landing.

Re: New speculative attacks on Apple CPUs

#334

Post by lxgr »

brookst wrote: post #324
fsflover wrote: post #318

Earlier quoted context omitted.

The alternative browsers have the required site isolation but aren't allowed. There's no fix for Safari and you must use it. I think it's very clearly decreasing the users' security.

Binary thinking is unhealthy. Alternative browsers would introduce other security concerns, including JIT. It’s debatable whether that would be a net security gain or loss, but it’s silly to just pretend it’s not a thing. Security as the product of multiple risks. Discovering a new risk does not mean all of the other ones evaporate and all decision making should be made solely with this one factor in mind.

Can you provide any arguments that JIT would in fact decrease security other than "Apple says so"?

Every major mobile and desktop OS other than iOS has supported it for over a decade. Apple is just using this as a fig leaf.

Re: New speculative attacks on Apple CPUs

#335

Post by lxgr »

brucehoult wrote: post #256
lxgr wrote: post #196

Earlier quoted context omitted.

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.

popup-based authentication does not actually need high performance.

It's not used only for authentication, and figuring out what a website is trying to do heuristically doesn't sound easy either (although I believe Chrome on Android does just that, and enforces a site-locked process when they deem it important for security reasons).

Re: New speculative attacks on Apple CPUs

#336

Post by coldpie »

thijsr wrote: post #33
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?

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.

In the context of a regular end-user desktop machine, this seems overly paranoid to me. The odds of encountering a real, JS-based spectre attack in the wild are basically zero (has anyone ever seen a browser-based Spectre attack outside of a research context? even once?), and the odds of it then being able to retrieve actual sensitive data are also basically zero. That's two astonishingly tiny numbers multiplied together. The threat just isn't there.

For regular end-user desktop machines, the mitigations only decrease performance for no real benefit. Spectre is a highly targeted attack, it's not something you can just point at any random machine to retrieve all their bank passwords or whatever.

Re: New speculative attacks on Apple CPUs

#337

Post by lxgr »

plufz wrote: post #283
lxgr wrote: post #163

Earlier quoted context omitted.

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

A lot of people did complain very loudly about enforcing SSL, and it took decades to get here. Same for cookies.

So yes, breaking changes for privacy/security reasons do happen, but they're very painful, and if there's a more secure alternative (in this case, still isolating communicating processes and providing communication via IPC, and providing an opt-out way of the legacy behavior), that's often the easier path.

Re: New speculative attacks on Apple CPUs

#338

Post by hmry »

saagarjha wrote: post #174
tptacek wrote: post #25

Cool detail, in the section where they reverse-engineer the presence of an LVP on the M3: Remarkably, while all other load widths activate the LVP on any constant value fitting that width, we observe that acti- vation on 8-byte wide loads occurs only when the load value is zero. We conjecture that this may be a countermeasure for memory safety such that the LVP will not learn values of pointers. That is, with the M3…

Grouping a hex address by threes is crazy

3 hex digits = 12 bits = 4096 entries, the size of each address translation table on ARM. So it does make some (twisted) sort of sense. Assuming you're using 4k page size

Re: New speculative attacks on Apple CPUs

#339

Post by ForOldHack »

tptacek wrote: post #29
gjsman-1000 wrote: post #7

Bizarre the M1 is immune to both; I'm more secure by not upgrading. (Sure, there's still a few, but they are mostly minor by comparison, or newer chips are also affected.)

The M1 doesn't have load address or value predictors. It's less sophisticated, and so has a smaller microarchitectural attack surface.

It has a power button, which effectively reduces the microarchitectural attack surface to zero.

Re: New speculative attacks on Apple CPUs

#340

Post by Rohansi »

brookst wrote: post #317
fsflover wrote: post #294

Earlier quoted context omitted.

> I'm not surprised to see this come back to bite them if after like 7 years Apple still hasn't adopted the only strong defense. So the Apple's argument that iOS can't have alternative browsers for security is a lie.

Strange claim. Security isn’t a one-bit thing where you’re either perfectly secure or not. If someone breaks into your house through a window and steals your stuff, that does not make it a lie to claim that locking your front door is more secure. In any event, Apple’s claim isn’t entirely true. It’s also not entirely false. Browsers absolutely require JIT to be remotely performant. Giving third parties JIT on iOS wou…

If JIT is such a problem then Apple shouldn't use it themselves. Sure, they let you disable it but it's still enabled by default while everyone pushes the narrative that Apple is all about security.
Post reply on HN