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,…
The RCE that AMD wouldn't fix
111–120 of 131 posts
Re: The RCE that AMD wouldn't fix
#112Re: The RCE that AMD wouldn't fix
#113Earlier 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.
Re: The RCE that AMD wouldn't fix
#114Earlier 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.
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
#115Earlier 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.…
Re: The RCE that AMD wouldn't fix
#116Earlier 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…
Re: The RCE that AMD wouldn't fix
#117Earlier 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.
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
#118Earlier 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.
Re: The RCE that AMD wouldn't fix
#119Earlier 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.
Re: The RCE that AMD wouldn't fix
#120Earlier 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.
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.