The RCE that AMD wouldn't fix (mrbruh.com)

The discussion the video references [1]

[1] - https://news.ycombinator.com/item?id=46906947

AMD didn't deny it was a vulnerability; they denied it was in the scope of the bounty program.

Remember that at giant tech companies, the incentive is to pay out bounties --- there are people on the vendor's team whose performance is measured in part by how much the program pays out.

Such a bug could have been exploited by certain big state actors.

Those that have access to international network links.

Those that have the ability to generate new firmware that simply passes the CRC32 checksum.

Actual write-up rather than overwrought YouTube drama: https://mrbruh.com/amd2/

A non-default-installation set of AMD tools (Ryzen Master and probably others) had an auto-updater which used HTTP instead of HTTPS. It's clear this is a feature they'd basically forgotten about; it even pointed to an ATI domain. A third-party bug bounty company rejected it because MITM was out of scope. AMD are incompetent at making software (news at 11), kept asking for extensions, and took an incredible amount of time to deal with it. Eventually they removed this updater entirely and replaced it with one in the app (rather than the installer) that uses HTTPS + a CRC32 (for some reason). The initial vuln was very stupid and should have been fixed faster. As for the current system, if you're mad about HTTPS-protected auto-updaters (which is valid), you've probably got a lot of them to go to war against.

Gaslighting does not mean lying.

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.

The "signature verification" in the fix being CRC32 is pretty hilariously clueless.

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

Seems like white hat work is pretty fruitless nowadays. Disappointing.

previously https://news.ycombinator.com/item?id=46906947

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!

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.

> If you are an AMD user...

Don't bother to use Windows?

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.

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.

Thank you for looking into this, I also have the annoying pop-up and have been suspicious of it…

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

Congratulations, you found the government backdoor!

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

Multi billion dollar company, by the way.

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