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.
The RCE that AMD wouldn't fix
11–20 of 131 posts
Re: The RCE that AMD wouldn't fix
#12Re: The RCE that AMD wouldn't fix
#13Earlier quoted context omitted.
Yeah, like the weird idea that those programs are intended to in some way reduce the number of exploitable bugs actually out there.
That's in fact often not their core purpose !
Nobody but AMD gives a fuck about AMD's internal policies or motivations.
Re: The RCE that AMD wouldn't fix
#14Re: The RCE that AMD wouldn't fix
#15Re: The RCE that AMD wouldn't fix
#16Re: The RCE that AMD wouldn't fix
#17It'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.
Re: The RCE that AMD wouldn't fix
#18Love this. I am frustrated by idiot software features everywhere, but am not triggered yet to punish them. AI automation is coming close however.
Re: The RCE that AMD wouldn't fix
#19Re: The RCE that AMD wouldn't fix
#20The "signature verification" in the fix being CRC32 is pretty hilariously clueless.