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

121–130 of 131 posts

Re: The RCE that AMD wouldn't fix

#121

Post by tgsovlerkhgsel »

This is a pretty common behavior that I've seen from bug bounty programs:

> a blog post discussing this issue has already been published, which does not appear to be in accordance with the program’s terms.

Companies reject bugs as out of scope and/or sit on them forever, then use the bug bounty ToS as intimidation to keep people from disclosing them. And sadly, it works.

I'm adding AMD to my list of companies that prefer their bug reports to be a public full disclosure rather than attempting to go through their bug bounty program.

Re: The RCE that AMD wouldn't fix

#122

Post by pseudohadamard »

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…

It's OK though, AMD is a US company so there's nothing to worry about. It's only when a Chinese company does the same thing that it's an evil CCP backdoor designed to destroy civilization.

Re: The RCE that AMD wouldn't fix

#123

Post by AlotOfReading »

brokenmachine wrote: post #120
AlotOfReading wrote: post #108

Earlier quoted context omitted.

The entire point of my post was that it's trivial, exactly as difficult as computing the CRC in the first place. Not sure why that was controversial. Nevertheless, they're still useful protection against noise, and you usually want to detect it right as you're pulling protocol messages off the wire. Placing checksums in the last field of each message (as Ethernet does) simplifies the hardware implementation.

It's fairly trivial, but still significantly harder than computing a single CRC. From stackoverflow: Because a 32-bit CRC yields only 2³² (approx. 4.29 billion) possible outputs, the Birthday Paradox dictates a 50% chance of an accidental collision after processing just ~77,000 unique inputs. I've done it for shits and giggles and from memory it took my desktop PC maybe 10 minutes to generate a collision. You're miss…

   It's fairly trivial, but still significantly harder than computing a single CRC.
You can do it with a single GF(2) multiplication, ignoring the complications of reflection and such. A normal CRC is just the special case of making the remainder 0 (again ignoring complications). You can also brute force it, but that's a bit slow for 64 bit CRCs and well, nanoseconds vs minutes in your example.

    Noise is not the only thing they should be protecting against.
Sorry, can you point to the comment where I tried to defend AMD's use of CRCs in this particular application? I think I've made it pretty clear that I don't think they're appropriate for cryptographic applications. I was just talking about the math.

Different tools for different purposes. You probably don't want to be using your mac scheme for noise resistance, because then you're paying a cost in either buffer space, PDU size, or retransmits, and your error correction capabilities are nil. CRCs allow some error correction (albeit rarely used and inefficient for multibit errors vs FECs), good bit error detection properties, and are cheap. It's common to use both at different layers of a protocol stack.

Re: The RCE that AMD wouldn't fix

#124

Post by nyanpasu64 »

gettingoverit wrote: post #110

The last time I remember, the green company did the same HTTP thing literally with their driver downloads from the website, and refused to fix it. Makes me wonder, how much of that 4 month delay was spent deliberating with the state actor. As if there was Prism, and both companies were legally bound to allow MitM to happen, and thus don't have a bug bounty for it.

It doesn't smell like a state actor to me, just gross negligence. Brushing up on the Reddit comment we wrote, the MITM isn't exploitable by default, since the client will error out at the 301 redirect and leave an obvious black window on the user's desktop. Exploiting a user would require replacing the 301 redirect with a direct download, which requires the same amount of effort whether the default disclosure was broken or not.

Now if they could've started shipping a modified AMD auto update that followed redirects, that would allow them to pwn users of the updated program. But it would do nothing to people who had installed older versions, up to the version the author installed (which left a black window open indicating the downloads never completed)...

Re: The RCE that AMD wouldn't fix

#126

Post by Avamander »

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…

Wacom does the same CRC-32 BS in their updater.

I blocked HTTP connections from my local network years ago and you wouldn't believe how many driver installers and auto-updaters break. One should never trust a HW vendor's (auto-)update implementation.

Re: The RCE that AMD wouldn't fix

#127

Post by Avamander »

asveikau wrote: post #62

> 124 days to get AMD to add an s to a couple of HTTP URLs! I disagree that they should only add HTTPS and call it done. They should also add some kind of signing check before running the payload. If anything I'd say HTTPS is optional if they do that part.

You'd imagine they'd just reuse and verify the Authenticode signature the very least.

Re: The RCE that AMD wouldn't fix

#128

Post by greenavocado »

ethbr1 wrote: post #87
cute_boi wrote: post #74

Earlier quoted context omitted.

AMD somehow got success, but their company culture and pay is shit. They expect PHD level experience but expect pay like peanuts....

> expect PHD level experience but expect pay like peanuts Thought this was par for the course in closer-to-hardware engineering. Never understood why the objectively way harder jobs pay so much worse as an industry.

Academic overproduction?

Re: The RCE that AMD wouldn't fix

#129

Post by J-Kuhn »

Terr_ wrote: post #102
Terr_ wrote: post #99

Earlier quoted context omitted.

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…

[Followup] To over-communicate in the hope that it somehow resolves things, we already have this chain of trust: 1. Axiom: We trust the current daemon and OS. We must assume this, because otherwise it's an entirely separate problem and this whole discussion of an auto-update channel is irrelevant. 2. Axiom: We trust the owner. Tampering with the local auto-update process is not part of our threat-model, because a use…

Or simply forgetting to renew the domain, at which point an attacker can deliver arbitrary files through correctly signed TLS.

Re: The RCE that AMD wouldn't fix

#130

Post by tiberious726 »

tptacek wrote: post #95
inlined wrote: post #91

Earlier quoted context omitted.

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…

Who would exploits be sold to then?
Post reply on HN