> 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 still trivial if someone compromises the webserver.
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.
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.
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 implications beyond dns…
Excluding SE is to make sure people do not spam customer support and launch annoying phishing campaigns. None of that is applicable for local software running on your own computer.
Out of scope does not necessarily mean out of impact. It is merely a question of how far a company wants to be responsible for the environment their software is run in. Most of the time that answer is "not much."
AMD's inability to make good software has been a recurring problem for decades. Many years ago I had some success with their optimising compiler, but everything else I've touched was bad. A real pity.
It's technically possible (though I don't know if they actually do this) that they're not referring to a signature check in the download part, but are verifying the code signing signature of the executable downloaded. You'd only notice the CRC if you were looking at the downloaded content, but if the updater refuses to launch an executable that isn't signed by AMD's cert then they would be fine.
Given the way AMD has been treating this issue, I'm assuming they're just incompetent, though.
The article has a screenshot of the decompiled code showing that they're just running the downloaded executable immediately, without any additional checks on the content.
Especially because if they had read about or studied this problem they would find tons of prior art where CRC32 was considered not secure for solving the problem. CRC32 solves a different problem -- how do you verify that the data that was received is identical to the data that was sent. It makes no guarantees about who is sending the data, which is the real problem signatures solve.
More specifically, it solves the problem of verifying that the data received was not accidentally corrupted somehow. Unlike cryptographic hashes, CRC32 does not do much to defend against deliberate, malicious modification. It's too easy to craft some different data that matches a given CRC32 value.
Computing a CRC is equivalent to attacking it. The checksum is the value that produces a certain fixed constant when appended to the data. This is why you'll often see checksums as the last field in a message. It allows for hardware to verify the entire message by checking if the CRC of the bytes equals that fixed constant without having to parse it.
AMD's utter incompetence when it comes to the software side of things is truly, truly baffling to me. It's not like you need a mountain of developers, a team or two on the right project would do wonders for their market share.
For example: Implement the CUDA. CUDA's won, hands down, that toothpaste is solidly outside the tube. Luckily, to the outside observer CUDA is just an API, and API's aren't copyrightable. Literally nothing is stopping AMD from hiring a relatively small team of developers to make AMD GPUs CUDA-compatible.
my suspicion is that it is the company culture: the hardware engineers are the real engineers. software is a triviality left for the lesser minds. the consequence is they mess up every product... everything they do needs software.
The argument I have read here on HN, is that CUDA is made for NVidia hardware, and the AMD hardware is not the best fit.
Essentially it forces AMD to play by NVidias rules, exactly like how they were forced to follow Intel rules. (Ignore for a second that the API / ISA boundary is different.)
But despite that, I also believe AMD would be better off just implementing CUDA.
HIP tries to be like this, almost API compatible with CUDA such that you just need to do find and replace. I think they even had a script to do this for you.
But the issue remains that the actual support and debugging tools remain so atrocious that it doesn't help to combat the CUDA monopoly. They've further burned a lot of trust by never really delivering on their promises to do better unless you're a customer large enough to get personalized attention from their engineers.
This ends up being a double whammy because not only are you pushing away smaller businesses, you're also pushing away single developers that go on to influence purchasing/development decisions.
There's two requests involved for the auto updater, one to grab the XML file, and one to grab the driver file over plain http.
If the autoupdater can't handle the redirection when grabbing the XML file, then it's a case of accidental safety by mistake that would prevent grabbing the plain http file.
I think we can all agree that MiTM is a valid attack vector and this should have paid out the bounty. AMD won't do it, but perhaps we can crowdsource it - the dude deserves it. Join me in doing this: https://ko-fi.com/mrbruhh (identical link to the one in the write up, feel free to verify).
I am a diehard fanboy of their GPUs, and have been since they were still ATI but I had to finally purchase an nvidia GPU because of how bad AMDs software quality is.
My powerful 5700XT spent two years basically broken, because the default, driver provided fan curve locked the fan at 27%. For two years, I couldn't figure out why my GPU constantly crashed, because it was overheating, because the default fan curve prevented the GPU from keeping itself cool and it would eventually just give up.
That diagnoses was complicated by the fact that AMD GPUs just resetting is very common. There's a watchdog timer in Windows that resets parts of the GPU stack because Microsoft is traumatized by 60% of Windows Vista BSODs being caused by bad nvidia drivers. Apparently sometimes if you increase this watchdog timer, the GPU eventually finishes whatever was giving it trouble.
But I still love AMD, and the ryzen line is a great value in the mid range. So I bought another AMD CPU and am very happy with it. But it somehow included software and this specific auto updater utility. Which I don't need, since I don't want to update the drivers for a GPU that I shouldn't be using (maybe except some video encoding lift, but my GPU can do that too). But I could not figure out a way to kill or prevent this stupid little autoupdater utility which always steals focus, for no reason at all. It shouldn't even be popping up a CLI! Windows task scheduling is incredible and would do this without a problem, and give you all the infrastructure to notice this was happening!
Drivers got better after ATI merged/got bought by AMD, but ATI has a loooooong legacy of terrible drivers in Windows.
The funny thing is, in Linux, the drivers are pretty great as far as I can tell. It's not like there aren't bugs, probably, but mostly everything "just works". You can't depend on FSR in Linux, for example - Doom Eternal just goes blank if you turn it on. I can live without it, though, and everything else seems fine, including performance.
Nvidia linux drivers make me quite upset - they're fine once you finally get them working, but you approach Nvidia driver updates with extreme caution in Linux
> 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 still trivial if someone compromises the webserver.
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.
MITM where attacker needs to install their own CA certs on the victim's device -- sure, out of scope.
MITM because you used http instead of https and you don't have any other verified cryptographic signature on your data -- get tae fuck, fix it pronto.
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.
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 implications beyond dns…
>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.
Excluding SE is to make sure people do not spam customer support and launch annoying phishing campaigns. None of that is applicable for local software running on your own computer.
Out of scope in this case means "we don't wanna pay you"
Apparently it also means "We don't want to pay our engineers to fix this".
Out of scope does not necessarily mean out of impact. It is merely a question of how far a company wants to be responsible for the environment their software is run in. Most of the time that answer is "not much."
But I use a Wi-Fi password, so my phone says it's secure!
AMD's inability to make good software has been a recurring problem for decades. Many years ago I had some success with their optimising compiler, but everything else I've touched was bad. A real pity.
The "signature verification" in the fix being CRC32 is pretty hilariously clueless.
It's technically possible (though I don't know if they actually do this) that they're not referring to a signature check in the download part, but are verifying the code signing signature of the executable downloaded. You'd only notice the CRC if you were looking at the downloaded content, but if the updater refuses to launch an executable that isn't signed by AMD's cert then they would be fine.
Given the way AMD has been treating this issue, I'm assuming they're just incompetent, though.
The article has a screenshot of the decompiled code showing that they're just running the downloaded executable immediately, without any additional checks on the content.
A manager somewhere made the embarrassingly wrong decision to not fix this, and they’re too egotistical to correct their mistake.
That’s my take.
Especially because if they had read about or studied this problem they would find tons of prior art where CRC32 was considered not secure for solving the problem. CRC32 solves a different problem -- how do you verify that the data that was received is identical to the data that was sent. It makes no guarantees about who is sending the data, which is the real problem signatures solve.
More specifically, it solves the problem of verifying that the data received was not accidentally corrupted somehow. Unlike cryptographic hashes, CRC32 does not do much to defend against deliberate, malicious modification. It's too easy to craft some different data that matches a given CRC32 value.
Computing a CRC is equivalent to attacking it. The checksum is the value that produces a certain fixed constant when appended to the data. This is why you'll often see checksums as the last field in a message. It allows for hardware to verify the entire message by checking if the CRC of the bytes equals that fixed constant without having to parse it.
They should have done base64 encryption before the crc32. noobs
AMD's utter incompetence when it comes to the software side of things is truly, truly baffling to me. It's not like you need a mountain of developers, a team or two on the right project would do wonders for their market share.
For example: Implement the CUDA. CUDA's won, hands down, that toothpaste is solidly outside the tube. Luckily, to the outside observer CUDA is just an API, and API's aren't copyrightable. Literally nothing is stopping AMD from hiring a relatively small team of developers to make AMD GPUs CUDA-compatible.
likewise. i'm bewildered throughout the years.
my suspicion is that it is the company culture: the hardware engineers are the real engineers. software is a triviality left for the lesser minds. the consequence is they mess up every product... everything they do needs software.
The argument I have read here on HN, is that CUDA is made for NVidia hardware, and the AMD hardware is not the best fit.
Essentially it forces AMD to play by NVidias rules, exactly like how they were forced to follow Intel rules. (Ignore for a second that the API / ISA boundary is different.)
But despite that, I also believe AMD would be better off just implementing CUDA.
HIP tries to be like this, almost API compatible with CUDA such that you just need to do find and replace. I think they even had a script to do this for you.
But the issue remains that the actual support and debugging tools remain so atrocious that it doesn't help to combat the CUDA monopoly. They've further burned a lot of trust by never really delivering on their promises to do better unless you're a customer large enough to get personalized attention from their engineers.
This ends up being a double whammy because not only are you pushing away smaller businesses, you're also pushing away single developers that go on to influence purchasing/development decisions.
> In my frustration, I decided to punish this software
Love this. I am frustrated by idiot software features everywhere, but am not triggered yet to punish them. AI automation is coming close however.
I got so mad at plex/jellyfin's crap I vibe coded an entire entertainment system out of spite.
Works great!
previously https://news.ycombinator.com/item?id=46906947
> If you are an AMD user...
Don't bother to use Windows?
Thank you for looking into this, I also have the annoying pop-up and have been suspicious of it…
There's two requests involved for the auto updater, one to grab the XML file, and one to grab the driver file over plain http.
If the autoupdater can't handle the redirection when grabbing the XML file, then it's a case of accidental safety by mistake that would prevent grabbing the plain http file.
Congratulations, you found the government backdoor!
Multi billion dollar company, by the way.
I think we can all agree that MiTM is a valid attack vector and this should have paid out the bounty. AMD won't do it, but perhaps we can crowdsource it - the dude deserves it. Join me in doing this: https://ko-fi.com/mrbruhh (identical link to the one in the write up, feel free to verify).
I started it with $100 - https://ko-fi.com/transactions/03df753c-09b0-4972-8e53-adf06...
AMD software is often utter trash.
I am a diehard fanboy of their GPUs, and have been since they were still ATI but I had to finally purchase an nvidia GPU because of how bad AMDs software quality is.
My powerful 5700XT spent two years basically broken, because the default, driver provided fan curve locked the fan at 27%. For two years, I couldn't figure out why my GPU constantly crashed, because it was overheating, because the default fan curve prevented the GPU from keeping itself cool and it would eventually just give up.
That diagnoses was complicated by the fact that AMD GPUs just resetting is very common. There's a watchdog timer in Windows that resets parts of the GPU stack because Microsoft is traumatized by 60% of Windows Vista BSODs being caused by bad nvidia drivers. Apparently sometimes if you increase this watchdog timer, the GPU eventually finishes whatever was giving it trouble.
But I still love AMD, and the ryzen line is a great value in the mid range. So I bought another AMD CPU and am very happy with it. But it somehow included software and this specific auto updater utility. Which I don't need, since I don't want to update the drivers for a GPU that I shouldn't be using (maybe except some video encoding lift, but my GPU can do that too). But I could not figure out a way to kill or prevent this stupid little autoupdater utility which always steals focus, for no reason at all. It shouldn't even be popping up a CLI! Windows task scheduling is incredible and would do this without a problem, and give you all the infrastructure to notice this was happening!
Drivers got better after ATI merged/got bought by AMD, but ATI has a loooooong legacy of terrible drivers in Windows.
The funny thing is, in Linux, the drivers are pretty great as far as I can tell. It's not like there aren't bugs, probably, but mostly everything "just works". You can't depend on FSR in Linux, for example - Doom Eternal just goes blank if you turn it on. I can live without it, though, and everything else seems fine, including performance.
Nvidia linux drivers make me quite upset - they're fine once you finally get them working, but you approach Nvidia driver updates with extreme caution in Linux
Seems like white hat work is pretty fruitless nowadays. Disappointing.
They keep choosing to work whitehat instead of blackhat, which is all AMD ever wanted.