Live data from Hacker News

The RCE that AMD wouldn't fix

mrbruh.com

111–120 of 131 posts

Re: The RCE that AMD wouldn't fix

#111
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 ...

There was a time when RDRAND on Zen gave all zeroes, or something, so eh... I'm happy enough with TLS introduced: knowing the server I'm reaching for updates is actually 'amd.com'. Signatures would be nice, sure, but I wouldn't consider them nearly as critical or useful until now . Before we get too caught up in signatures, however, I'd like to see their new/improved updater actually take precedence. As things stand,…

I prefer 7 myself, but 0 is a perfectly good random number.

Re: The RCE that AMD wouldn't fix

#112
Hilarious read. I laugh out loud multiple times during the read. In the end, I think amd should pay the author simply for the will of debugging for a broken software written by amd, as well as the sheer amounts of loose ends this exploration leads to.

Re: The RCE that AMD wouldn't fix

#113

Earlier quoted context omitted.

There was a time when RDRAND on Zen gave all zeroes, or something, so eh... I'm happy enough with TLS introduced: knowing the server I'm reaching for updates is actually 'amd.com'. Signatures would be nice, sure, but I wouldn't consider them nearly as critical or useful until now . Before we get too caught up in signatures, however, I'd like to see their new/improved updater actually take precedence. As things stand,…

I prefer 7 myself, but 0 is a perfectly good random number.

Ah, well, they disagreed and patched it. Now we get no say.

Re: The RCE that AMD wouldn't fix

#114

Earlier quoted context omitted.

How do we know the incentive is to pay out bounties? And how do we know that doesn't change on the whims of the management chain? We don't "know" anything unless we are at that company in particular and part of the management conversations. We at best can theorize based on incentives, but that's assuming companies and people are logical, which is a large assumption. I could easily see someone in the midst of layoffs…

You're right. AMD could for some reason be unlike every other major tech company that runs a bug bounty. Maybe AMD stood up a public bounty where people get their pay docked when bounties get paid, rather than perfed up. They would potentially save, say, 0.000289% of their annual revenue, in exchange for stories like these. Checks out.

I'm not claiming to know how any major tech company runs their bug bounty program. I'm actually trying to claim that we can't know how AMD (or any of them) do, we can merely express our opinions on it. We can discuss all the public incentives they may have (and our interpretations on how those incentives should play out), but we don't see the internal bureaucratic incentives or the personal incentives or etc etc etc.

We also regularly see how the incentives we see as outsiders (and somewhat insiders) are regularly perverted. For the VW emissions scandal someone could have argued that the incentives were plain and clear, "Design better engines", but they instead went with "Design better ways to scam the tests". This is on top of the way companies will mask their true incentives, like how renewable energy programs are sometimes actually just the smart financial decision but it'll be portrayed as part of the green movement.

To include some explicit personal opinion, I can't throw a stone without hitting a news story about a company that thought they could get away with something but then eventually got called out by it... and they ultimately still got away with it.

Re: The RCE that AMD wouldn't fix

#115

Earlier quoted context omitted.

You're right. AMD could for some reason be unlike every other major tech company that runs a bug bounty. Maybe AMD stood up a public bounty where people get their pay docked when bounties get paid, rather than perfed up. They would potentially save, say, 0.000289% of their annual revenue, in exchange for stories like these. Checks out.

I'm not claiming to know how any major tech company runs their bug bounty program. I'm actually trying to claim that we can't know how AMD (or any of them) do, we can merely express our opinions on it. We can discuss all the public incentives they may have (and our interpretations on how those incentives should play out), but we don't see the internal bureaucratic incentives or the personal incentives or etc etc etc.…

This is not the VW emissions scandal.

Re: The RCE that AMD wouldn't fix

#116
post #32

Earlier quoted context omitted.

What is it?

(First, I'm sorry I was so terse upthread; I had to get up early for a meeting and was scrolling HN in bed while it was happening without my reading glasses on; I should learn to stop commenting when I'm like that.) I've written about this before here, but to sum it up: * Unless something wild happens in software engineering (formal methods, &c) as a result of AI, there's no such thing as eradicating security vulnera…

Then the guy should have let the public know about it 124 days ago. If AMD doesn't care, the discoverer shouldn't either.

Re: The RCE that AMD wouldn't fix

#117

Earlier quoted context omitted.

I'm not claiming to know how any major tech company runs their bug bounty program. I'm actually trying to claim that we can't know how AMD (or any of them) do, we can merely express our opinions on it. We can discuss all the public incentives they may have (and our interpretations on how those incentives should play out), but we don't see the internal bureaucratic incentives or the personal incentives or etc etc etc.…

This is not the VW emissions scandal.

I'm aware that AMD was not involved in the VW scandal, and that that's not what TFA is about. Was that not clear?

It was a pop culture example of incentives gone wrong to hopefully support why incentives aren't clear cut.

Re: The RCE that AMD wouldn't fix

#118
post #32

Earlier quoted context omitted.

(First, I'm sorry I was so terse upthread; I had to get up early for a meeting and was scrolling HN in bed while it was happening without my reading glasses on; I should learn to stop commenting when I'm like that.) I've written about this before here, but to sum it up: * Unless something wild happens in software engineering (formal methods, &c) as a result of AI, there's no such thing as eradicating security vulnera…

Then the guy should have let the public know about it 124 days ago. If AMD doesn't care, the discoverer shouldn't either.

Absolutely.

Re: The RCE that AMD wouldn't fix

#119
post #52

Earlier quoted context omitted.

Why would anyone ever exclude true mitm? Various domain registrars have been compromised over and over again (often by children!), resulting in companies like Tesla and Cloudflare getting owned. The reality is that any vaguely competent attacker can compromise a court clerk and just compel e.g. the .com registry to hand over whatever domain they want. Although I suppose the aforementioned problem has significant impl…

>Why would anyone ever exclude true mitm? Same reason security programs exclude social engineering, even though that's a pretty common way for companies to get pwned.

Sure, but this is more akin to dismissing a 1click RCE as “social engineering” because an employee has to be convinced to click a link.

Re: The RCE that AMD wouldn't fix

#120

Earlier quoted context omitted.

It's trivially easy to create a malicious file with the same CRC as another file. So "verifying" using CRC is very stupid if you're trying to prevent malicious execution. You need to use cryptographic signatures.

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 missing the point though.

Noise is not the only thing they should be protecting against.

The point is that AMD is executing code based on checking using an algorithm that has barely any protection from malicious inputs, which is stupid, and not fixing it just compounds that stupidity.

A cryptographic signature protects against both noise and malicious inputs.

Post reply on HN