Hacker News Reader

Comment by tptacek | Hacker News Reader

These are not pedestrian vulnerabilities. Not only do they appear to destroy the security of the PSP enclave system AMD uses, but it actually makes systems that have the PSP less secure than systems that do. They're essentially the worst possible vulnerabilities you can find in a security coprocessor.

If you'd found the same class of vulnerabilities in Intel SGX or the iPhone SEP, you'd have a contender for the top vulnerability discovery of the year; an almost-lock on the Pwnie.

I simply can't understand the people who are downplaying this other than by assuming that people love AMD so much that they don't want these to be severe vulnerabilities.

Do I think this will move the stock? No. I don't think an SGX break would hurt Intel much either.

View on HN

Aren't these the same level as the Intel ME vulnerabilities? I'm basically assuming this is wonderful schadenfreude to see that AMD is basically no better than Intel at protecting this sort of stuff.

When I say "pedestrian" vulnerabilities, what I mean is that most users should wait for the patch to come out and apply it, but otherwise not panic. It's definitely not Heartbleed-class "you need to have patched yesterday and, if you haven't, you're already compromised."

Yes, these are comparable to ME vulnerabilities, which were plastered all across the HN front page and had people asking how they could find parts that didn't have MEs or whether they should switch to AMD.

Weren't the ME vulnerabilities remotely exploitable? If so that's not the same at all as what we're talking about here.

'Persistent exploit' and 'Remote exploit' are surely both in some very high category of badness, it seems weird to say they are not the same at all.

The are not. Remote is far worse as it usually enables compromise (via privilege escalation most of the cases) and persistence without need for a previous break or physical presense.

These reported errors, while quite severe for what i've been able to make out of the less-than-good paper, do not grant a primary mode of attack and do not provide a way of getting privileges. Just a way of keeping it forever and ever and ever and ever ...

Should be fixed and done properly, just get the fucking CVEs already and publish it ... It is highly likely that it's in some way applicable to other secure elements on other cpu's as well so a proper response is needed.

CVEs are something that people who don't do vulnerability research seem to care about a lot more than people who do. What difference do you suggest it makes whether CTS-Labs gets them allocated or AMD does?

"The are not."

The basis of this is mostly you just saying it emphatically, as far as I can tell. Most real-world exploits rely on a combination of vulnerabilities. What's a sensible ranking of 'remote' over 'persistent'?

just get the fucking CVEs already

What does this really have to do with anything? It's hard to imagine anyone dealing with a real deployed system saying 'Well, since there is no CVE, this does not affect us at all".

Remote means you're already compromised. Persistent means you can't easily recover from a compromise.

No.

"Persistent when you overwrite firmware after cracking update key" is not very persistent at all.

I think these "amdflaws" vulnerabilities very much deserve to be discussed, and as somebody who doesn't like these blackbox enclaves in modern architectures I'm pretty happy to be proved right once again.

That being said with their shady behaviour CTS-labs have managed the tour de force of overshadowing these vulnerabilities with their botched hit piece "reveal". Paradoxically AMD might end up receiving less backlash than they deserve for their shoddy work because the researchers tried to pull a quick scam out of it. Great job CTS-labs.

From your source:

> "All exploits require the ability to run an executable as admin"

> "There is no immediate risk of exploitation of these vulnerabilities for most users."

> "These types of vulnerabilities should not surprise any security researchers; similar flaws have been found in other embedded systems that have attempted to implement security features."

Sounds pretty pedestrian.

To be clear, ToB is not trivializing the vulnerabilities. In particular, your second and third quote here are equally applicable to most serious vulnerabilities found in e.g. iOS.

>but it actually makes systems that have the PSP less secure than systems that do.

Parse error. Did you mean "than systems that don't"?

Perhaps I'm missing something, but don't these vulnerabilities require root to exploit?

That is the attack surface for a secure coprocessor vulnerability!

It's also what makes the vulnerabilities not-that-bad. It's just another "peripheral not properly handling firmware updates" thing, which are all over the place.

I mean, it's cool from a security research perspective, the PSP isn't just some random keyboard/HDD, but the severity seems overstated.

I'm not here to argue that CTS-Labs or Viceroy didn't overstate the vulnerabilities. Surely, Viceroy did! They said the stock was heading for zero!

I'm saying that the inverse argument, that the vulnerabilities are "pedestrian" and not worth making noise about, is at least equally false.

Unfortunately, the day of the announcement, several people trafficked in opinions based on CTS-Labs white paper --- which any skilled reader knew immediately, just from the format, wasn't a technical explanation --- that these vulnerabilities were non-issues. If I see people repeating that notion, I'm going to point out: the equivalent vulnerability in the iPhone platform would be front-page news.

Did AMD pull off a next level PR move here? I run a threadripper on my home box that holds keys that need to stay private. Is there anything I can do to mitigate venerability or should I start a painful key rotation process and keep them only on my MBP until a patch is out?

> I run a threadripper on my home box that holds keys that need to stay private. Is there anything I can do to mitigate venerability or should I start a painful key rotation process and keep them only on my MBP until a patch is out?

Yep, you should consider them burned. Also make sure you stock up on tinfoil too as you’ll need to make sure the fresh replacement keys don’t get mind read from a distance.

</sarcasm>

In all seriousness, what part of this situation would lead you to think what you’re saying? There’s been good coverage of what it’d take to exploit these vulnerabilities, so I’m not sure what lead you to this line of reasoning.

Are you storing those keys in the TPM or a smartcard? Is the machine connected to the Internet, or even to the local network? In other words ask yourself if the keys would be compromised by anyone getting root on the machine, and then:

* if yes, what are the ways that one could get root on that machine? Is it better or worse on the MBP?

* if not, are the keys stored in a place which is related to the secure processor?

And also: is there a reason why somebody could 1) know that you have keys on that machine 2) be interested in those keys 3) have the resources to conduct the attack?

In a nutshell, analyze your attack surface and model your threats.

Get a proper smartcard, don't let it be connected all the time (remove when not needed) and if they need to be kept private really badly, for the love of god don't connect it to the internet in any way.

Reply on news.ycombinator.com