Live data from Hacker News

New speculative attacks on Apple CPUs

predictors.fail

261–270 of 365 posts

Re: New speculative attacks on Apple CPUs

#261

Earlier quoted context omitted.

> Individuals could choose a "secure" browser or browser mode that provides increased protection from such attacks or a "compatible" one that is less likely to break old websites. And then we get thousands of posts whining about Safari being broken because it is "not like Chrome" and developers moaning that their unsafe pet API is not supported. Web developers are never going to play ball.

idunno, as a professional web dev since 1998, I don't understand why Google, Apple and Mozilla are trying so hard to make the web browser like a complete OS (I technically understand why, I just think it's ridiculous). The amount of obscure APIs being added just boosts the surface area for vulnerabilities and makes low-resource web browsing nearly impossible. You either get "a web browser that works" or "a web browse…

> The amount of obscure APIs being added just boosts the surface area for vulnerabilities

It’s often the ancient APIs from around 1995-2001 that are the most vulnerable ones, with information leaking across origins (like todays) needing hacky fixes to stay secure and compatible.

window.open(), target=_blank, cross site request forgery, etc.

IE6 from 2001 had a ton of these modern security issues, and Netscape before it probably had them too.

At that time there were tons of buffer overflow security holes so no on cared about side-channel attacks.

Re: New speculative attacks on Apple CPUs

#262
post #188

Earlier quoted context omitted.

Well, for better or worse, the web is an application platform these days. I consider it pretty great, since the alternative is installing native apps for things I'm using exactly once or very rarely. There's a case to be made though that maybe these things should only be available to PWAs, which is what Apple is already doing for some functionality on iOS, including push notifications.

What? I thought Apple was trying to quietly kill pwas, probably bc they don't go thru their app store. And also bc if you make a good enough sandbox then you don't need to pay for "all the wooork we put in"

They certainly don’t have a lot of love for them as a first-class app development environment, but they are also their fig leaf of “open access” to the platform.

Regardless of that, I do like the idea of PWAs getting access to a higher tier of web APIs, especially those increasing the attack surface, as “installing an app” makes even non-sophisticated users do more of a double take than “visiting a website” in terms of access to their system.

Re: New speculative attacks on Apple CPUs

#264
post #33
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.

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 I place an online order?

Re: New speculative attacks on Apple CPUs

#265
post #118

Earlier quoted context omitted.

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

[flagged]

Re: New speculative attacks on Apple CPUs

#266
post #221

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.

Yes.

Re: New speculative attacks on Apple CPUs

#267

This introduced me to the idea of load value predictors. Is Apple the only chip designer using these in commercially released microarchitecture?

from doing some work on GC a couple years ago, at that time apple was the only one with it. The performance is awesome, it makes graph traversal ~2x faster.

Re: New speculative attacks on Apple CPUs

#268

Earlier quoted context omitted.

As someone who followed a course on all of this, this is indeed how we started out. 1. Read Flush + Reload 2. Then reproduce it in C 3. Then read Meltdown 4. Reproduce it in C 5. Read Spectre 6. Reproduce it in C After that we had to implement a VUSEC paper. I chose GLitch [1]. [1] https://www.vusec.net/projects/glitch/

Keep in mind that getting meltdown to work might be very difficult depending on your setup. I wouldn't have been able to at least when starting out my teacher didn't provide us with targetable hardware. A spectre (particularly RSB-based ones) are nice to start out with imo.

Yea fair, this is obviously a high level overview. I think I found with meltdown that I needed the assembly code. I also was able to reproduce it with actual C code if I recall correctly but that was way more finnicky.

Re: New speculative attacks on Apple CPUs

#270
post #166

Earlier quoted context omitted.

Have you noticed how often people complain Chrome uses too much memory?

Process-per-site isolation doesn't necessarily have to use (much) more memory. If you pre-initialize the renderer and JavaScript engine and then fork that pre-warmed instance for each site, every page of memory not written to remains shared in physical memory. Properly accounting for that in task managers is hard, though; on many OSes, Chrome's memory usage looks much scarier than it is in reality.

Not possible on Windows, where most Chrome users are on.
Post reply on HN