Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The RCE that AMD wouldn't fix

mrbruh.com

Post reply on HN
Print view View original

91–100 of 131 posts

Re: The RCE that AMD wouldn't fix

#91

Post by inlined »

tptacek wrote: post #67
tlb wrote: post #15

It's ridiculous to consider MITM attacks out of scope for taking over your computer. Also, there are probably ways to exploit this without a true MITM like DNS cache poisoning. But it's best to just assume the whole internet is MITMed.

It's not out of scope "for taking over your computer". It's out of scope for the specific goals of the bug bounty program. Bug bounties are (usually) about prioritizing internal engineering effort; they are to vulnerability remediation what market feedback is to feature/function decisions in the rest of the product. Everyone's judging this by the standard of "how good a bug" this is. But that's not necessarily how a…

But it should be their job to protect against MitM in their threat model. There is no rational reason to exclude them from the bug bounty. Doing so only leaves MitM attacks like this undisclosed.

Re: The RCE that AMD wouldn't fix

#92

Post by inlined »

arcfour wrote: post #53
pietervdvn wrote: post #41

Earlier quoted context omitted.

I'd even count this as "having local access to the device", as that is what is needed to install such a cert

I think it's fair to say that requiring local administrative access to the device is out of scope, since you have already completely pwned the device in that case, which is what what you need to install a CA cert on any OSes.

In honor of The Old New Thing I call these “Vogon vulnerabilities”: I have a marvelous exploit in mind that pwns anyone I have root access to

Re: The RCE that AMD wouldn't fix

#94

Post by rwmj »

SahAssar wrote: post #78
rwmj wrote: post #76

Earlier quoted context omitted.

AMD (and Intel and everyone else) processors already have an HSM inside for confidential computing so use that? I would hope the HSM isn't as badly implemented as this update mechanism, but then again ...

Those have been broken again and again. Even if not, how do you distribute the public keys for it, how do you bootstrap that trust?

Confidential computing is a whole thing with a key in each processor and a chain of trust and a way to remotely attest that your software is running in a secure enclave. All the vendors do it differently (sadly) but it's very much a solved problem.

Re: The RCE that AMD wouldn't fix

#95

Post by tptacek »

inlined wrote: post #91
tptacek wrote: post #67

Earlier quoted context omitted.

It's not out of scope "for taking over your computer". It's out of scope for the specific goals of the bug bounty program. Bug bounties are (usually) about prioritizing internal engineering effort; they are to vulnerability remediation what market feedback is to feature/function decisions in the rest of the product. Everyone's judging this by the standard of "how good a bug" this is. But that's not necessarily how a…

But it should be their job to protect against MitM in their threat model. There is no rational reason to exclude them from the bug bounty. Doing so only leaves MitM attacks like this undisclosed.

I just gave a rational reason to exclude them from the bug bounty, which I can summarize as "the bug bounty is not their entire security program and does not have the goal you've axiomatically derived for it".

Cards on the table I am not a fan of bug bounty programs, and the fact that they're an engineering process that turns out to be impossible to have public engineering discussions about is definitely one of many reasons why. Most companies should not run bug bounty programs.

Re: The RCE that AMD wouldn't fix

#96

Post by [deleted] »

lazide wrote: post #90
SahAssar wrote: post #89

Earlier quoted context omitted.

> The current installation shall already contain one (or more) public keys that it trusts for updates The current installation was fetched via HTTPS, right? Either by you or in the factory. Just saying the "bootstrapping already happened" does not make it not happen. It still needs to bootstrap trust from somewhere

Sure, but the OEM is the definition of a ‘trusted environment’. They literally are assembling the equipment, if you can’t trust that, nothing else can be trusted from that point on anyway.

[deleted]

Re: The RCE that AMD wouldn't fix

#97

Post by [deleted] »

SahAssar wrote: post #89
Terr_ wrote: post #82

Earlier quoted context omitted.

What? The bootstrapping happened already! The official and correct AMD software already running on the computers. Preventing a human from falling for an impostor-website with malicious Download Now links is a separate problem. The basics are straightforward: It'd be better if the current installation contains one (or more) public keys, and anything it downloads must validate as being signed by a corresponding private…

> The current installation shall already contain one (or more) public keys that it trusts for updates The current installation was fetched via HTTPS, right? Either by you or in the factory. Just saying the "bootstrapping already happened" does not make it not happen. It still needs to bootstrap trust from somewhere

[deleted]

Re: The RCE that AMD wouldn't fix

#99

Post by Terr_ »

SahAssar wrote: post #89
Terr_ wrote: post #82

Earlier quoted context omitted.

What? The bootstrapping happened already! The official and correct AMD software already running on the computers. Preventing a human from falling for an impostor-website with malicious Download Now links is a separate problem. The basics are straightforward: It'd be better if the current installation contains one (or more) public keys, and anything it downloads must validate as being signed by a corresponding private…

> The current installation shall already contain one (or more) public keys that it trusts for updates The current installation was fetched via HTTPS, right? Either by you or in the factory. Just saying the "bootstrapping already happened" does not make it not happen. It still needs to bootstrap trust from somewhere

I still can't figure out what problem you believe needs-fixing or what process you think needs to be explained. My most-charitable guesses are:

A. You're asking what should be done if the manufacturer's auto-update server has already been completely compromised by hackers and remains compromised.

B. [Implicitly rejected in last coment] You're asking how anybody can guarantee the very first install can be trusted even if someone has compromised drivers.amd.com .

C. You're asking if the auto-update process can somehow trick a compromised daemon into overwriting itself with a legit copy.

Those are all interesting to contemplate, but they are at best "out of scope".

Re: The RCE that AMD wouldn't fix

#100

Post by LearnYouALisp »

DANmode wrote: post #79
Terr_ wrote: post #48

> Final update: A couple of days before the embargo ended (and after I wrote the majority of this blog post), AMD told me what their patch for this vulnerability is [...] Although it is true that they now fully use HTTPS, the claim about signature verification is untrue; they only perform a CRC-32 check on the downloaded executable, which is not cryptographically secure. So solves the MITM, but massive infection is s…

> someone

"Things break, Colonel!"
Post reply on HN