Live data from Hacker News

New speculative attacks on Apple CPUs

predictors.fail

361–365 of 365 posts

Re: New speculative attacks on Apple CPUs

#361

Earlier quoted context omitted.

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.

JIT isn’t the problem. It’s giving control of JIT to third parties.

We can still hate on Apple, it’s just more accurate to say they don’t trust their own app sandboxes to stand up to LLVM / assembly attacks from malicious apps with JIT access.

Re: New speculative attacks on Apple CPUs

#362
post #215
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…

Can't edit my original post anymore: Firefox and Chrome do seem to isolate even same-browsing-context-group and bridge the required APIs via IPC, so hopefully Safari will catch up at some point. Basically, there are three scenarios: - Completely unrelated tabs (e.g. those you open manually, those opened via command-click, tabs opened via ' " or 'rel="noopener"' references etc.) – these are relatively easily isolated…

Does Safari always open sites in separate processes when manually opening a new tab (e.g., via Command+T or via another macOS app sending a link to be opened by Safari) instead of allowing a webpage in one tab to open a link in a new tab via window.open? If so, does that prevent the SLAP attack from working against the contents of those manually opened tabs? Wouldn't the best practice, then, be to (1) never login to a website (or access a site where you are already logged in) by clicking a link on another site, and (2) when browsing a site where you are logged in, never click a link to another website, but instead copy the link, manually open a new tab, and then paste the link into the address bar? Obviously, that's cumbersome and annoying, but if it mitigates SLAP, then maybe it's worth the effort.

Re: New speculative attacks on Apple CPUs

#363

Earlier quoted context omitted.

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.

JIT isn’t the problem. It’s giving control of JIT to third parties. We can still hate on Apple, it’s just more accurate to say they don’t trust their own app sandboxes to stand up to LLVM / assembly attacks from malicious apps with JIT access.

> It’s giving control of JIT to third parties

Any real-world examples demonstrating how it's insecure? Here and now it demonstrably decreases the security.

Re: New speculative attacks on Apple CPUs

#364

Earlier quoted context omitted.

> it uses that's mostly 4x4 which is not very large That's 16x32 which is AVX512. What other size would you suggest using and (more importantly) what commercially available CPU architecture are you running it on?

4x4 is 4x4, not 16x32?

[dead]

Re: New speculative attacks on Apple CPUs

#365

Earlier quoted context omitted.

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.

JIT isn’t the problem. It’s giving control of JIT to third parties. We can still hate on Apple, it’s just more accurate to say they don’t trust their own app sandboxes to stand up to LLVM / assembly attacks from malicious apps with JIT access.

I just don't buy that it's a special security concern at all. There are so many other possible security vulnerabilities to exploit that don't involve a JIT compiler. So why would Apple specifically restrict third party apps from JIT?

It's realistically just another way to ensure they maintain control over app distribution. Safari sucks for web apps. Third party browsers are just different shells over Safari on iOS. Apps built on things like React Native support hotfixing without slow app store reviews - but your app will be slow without JIT and rules force you to still go through reviews for feature changes.

There's no issue with any of this on Android.

Post reply on HN