Hacker News Reader

Comment by supernova87a | Hacker News Reader

I wonder if Apple/others knew about such vulnerabilities, and passed up on using the chip as a risk? Or, was it just dumb luck that they avoided this?

View on HN

From Apple's perspective Qualcomm has been insufficient for a long time for many reasons, the security issues here would only be one of the many factors involved in the decision to do their own development.

For what it is worth, a modern chip as complex as the A* series is essentially guaranteed to have vulnerabilities. Maybe not 400, but definitely not 0.

This is a thing I think people constantly underestimate... Intel's cores are not necessarily dramatically more broken than everyone else's chips, they just pay for more auditing and public research.

> they just pay for more auditing and public research.

Did Intel finance the research that turned up any of the major headline vulnerabilities over the last few years (meltdown, spectre)?

They did not.

It was a Google researcher mostly.

> Meltdown was independently discovered and reported by three teams:

Jann Horn (Google Project Zero), Werner Haas, Thomas Prescher (Cyberus Technology), Daniel Gruss, Moritz Lipp, Stefan Mangard, Michael Schwarz (Graz University of Technology)

Spectre was independently discovered and reported by two people:

Jann Horn (Google Project Zero) and Paul Kocher in collaboration with, in alphabetical order, Daniel Genkin (University of Pennsylvania and University of Maryland), Mike Hamburg (Rambus), Moritz Lipp (Graz University of Technology), and Yuval Yarom (University of Adelaide and Data61)

https://meltdownattack.com/#faq-systems-meltdown

A quick survey of the papers published in 2019 and later (i.e., post Meltdown/Spectre, inclusive) listed at [1] indicate that Intel contributed financial support to the majority of them. ARM was the second-most corporate contributor, followed by AMD.

[1]: https://gruss.cc/

Even if they wouldn't, I imagine the exposure is enough. Windows, Android, Linux probably have more eyes on them than all the other software in the world, combined.

"If you want half the world's hackers to audit your code, put it in an Apple product. If you want all the world's hackers to audit your code, put it in a Nintendo product."

Please tell me where this came from, and that it's not just something you made up?

It came from GPT-3.

Just kidding.

> they just pay for more auditing and public research.

Who is Intel paying to audit their chips?

Anyone who wants to report something via their bug bounty program.

https://www.intel.com/content/www/us/en/security-center/bug-...

Auditing/public research and bug bounties are not really the same category.

Famously, telegram has a bounty program- but was widely criticised for it, and for not doing a formal audit.

Criticisms here: https://news.ycombinator.com/item?id=6940665

I don’t doubt that they have more independent security analysis than just the bounty program; but using it as an argument that they’re paying people is not realistic.

Bug bounties are very different than auditing. In an audit, there is a contract in place with specific analysis objectives based on agreed-upon criteria. I find it unlikely anyone in the industry would have more experience than Intel about CPU manufacturing, although there might be security consulting firms that are advanced enough to merit a real corporate NDA. But given the breadth and depth of their IP, even that seems unlikely.

But I would still really be interested to know who Intel hires to audit their products, if this is true. I'd like to do that kind of work.

This is very much an opinion, not a fact. "Intel is only in trouble because they got caught, AMD is surely incompetent as well, but hasn't been found out".

A google scholar search for "amd security" turns up less than 100k results while a search for "intel security" has <2 million results.

ok, but what's the ratio of the number of Intel cpus running on something worth hacking compared to the number of amd CPUs?

My point is that there is more academic research on Intel processors than AMD. For a hacker, an Intel vulrability would of course be more lucrative than a AMD one.

"Intel" has another meaning, especially when placed next to the word "security". The number of results from your two google searches is meaningless.

That number is literally the most meaningful number there. Meltdown caused more scare than all of these 400 bugs described here, just because intel is not expected to have any sort of vulnerability and the people who really care about security chooses intel(not talking about self described privacy pundits on HN, but military and banks). There had been much more research on intel security than all other chips combined.

That's a good point, about half the results go away when you add "processor" to the query. Interestingly, the same happens for the AMD query so the ratio is still similar.

I dont think it has much to do with competence, the order of complexity in these chips are reaching super human levels of intellect to decipher. Finding vulnerabilities is hard but safeguarding against them is even harder. Take 'spectre' for instance, it is a fundamental problem with the speculative architecture can't really get rid of it.

The most "broken" thing about Intel's chips was discovered by Google

Isn't this why apple doesn't trust the CPU with secure functions and has dedicated hardware for it? So a vuln in the cpu won't expose the encryption keys bypassing face id.

Hard to tell anyone's intentions, but that's probably, at least partially, a side effect.

Apple seem to use security primarily for two things, marketing, and to ensure they have control over the platform, and the developers who write applications for it.

Maybe that's three things? Anyway, the totality of what they do in security isn't user centric enough that the reason for external security hardware would be to primarily increase the user security. Obviously they have to do this (increase user security) to make it palatable to the customer, but there's a certain asymmetry in their actions that makes it seem unlikely that actual increased user security was the original goal.

Looking at the slides from a different article, these are not really in the chip per say but in the SDK. So any lib compiled to use the chip would be affected but not really a hardware issue. Basically fuzzy testing found 400 library calls that fail with segfaults. These can sometimes (but not always) be modified to do a takeover, but I didn't see anyone claiming to have done that.

It's even more intentionally misleading than that. The SDK generates wrapper libraries that allow you to interface with your code running on the DSP. Some of the wrapper functions generated have vulnerabilities. The 400 vulnerabilities are the few vulnerabilities found in the SDK template multiplied by how many different generated wrapper libraries they found.

So you fix the handful of errors in the SDK templates and all the 400 vulnerabilities go away.

The implication is that Apple's own chips are somehow bug-free, which they probably aren't.

If you have connections to the real infosec world. They'd avoid it.

Not sure what you mean?

Reply on news.ycombinator.com