The RCE that AMD won't fix • Hacker News Board

Re: The RCE that AMD won't fix

#121

Post by M95D » Fri, Feb 06, 2026, 1:58 PM UTC

Symmetry wrote: post #111

aleph_minus_one wrote: post #28

Earlier quoted context omitted.

> For whatever reason, distro maintainers working for free seem a lot more competent with security than billion dollar hardware vendors I don't believe that these billion dollar hardware vendors are really incompetent with security. It's rather that the distro maintainers do care quite a bit about security, while for these hardware vendors consider these security concerns to be of much smaller importance; for their b…

Years of working in embedded computing have left me with the impression that most hardware companies are just bad at software. I think part of it is that the long cycle times of making hardware push them towards a culture of waterfall development. But years of working with the microcontroller libraries for ethernet PHYs, the bash scripts to build the kernels for SoCs, etc make me perfectly willing to believe they are…

And which are the companies that are good at software? Please, give at least one example.

Re: The RCE that AMD won't fix

#122

Post by pmontra » Fri, Feb 06, 2026, 2:00 PM UTC

thedanbob wrote: post #110

pmontra wrote: post #109

Earlier quoted context omitted.

If somebody is MITMing a target person, they will respond positively to "update available?" calls from that person and then serve the tainted update. The article does not say what the frequency of auto update check is. Let's say one per day. If somebody is targeted it's one day away from RCE.

The update check is HTTPS, only the files themselves are HTTP.

I missed that, thanks!

Re: The RCE that AMD won't fix

#123

Post by zeendo » Fri, Feb 06, 2026, 2:03 PM UTC

ZiiS wrote: post #88

krater23 wrote: post #84

Earlier quoted context omitted.

And you have them in your laptop? Or just using your phone and don't own a laptop at all?

I would use my phone's 'hotspot' long before I tried random wifi on my laptop?

Are you being willfully obtuse or do you actually believe that's true of everyone? There are so many reasons why someone might have a laptop in such a situation but not be able to use a hotspot on their phone - it's not even worth listing them.

Re: The RCE that AMD won't fix

#124

Post by yrro » Fri, Feb 06, 2026, 2:20 PM UTC

Avamander wrote: post #103

This is why I've blocked all HTTP traffic outgoing from my machines. A lot of people have brought this up over the years: https://www.reddit.com/r/AMDHelp/comments/ysqvsv/amd_autoupd... (I'm fairly sure I have even mentioned AMD doing this on HN in the past.) AMD is also not the only one. Gigabyte, ASUS, many other autoupdaters and installers fail without HTTP access. I couldn't even set up my HomePod without allowin…

Doesn't this break CRL fetching and OCSP queries?

Re: The RCE that AMD won't fix

#125

Post by jbstack » Fri, Feb 06, 2026, 2:49 PM UTC

tw04 wrote: post #99

jbstack wrote: post #91

Earlier quoted context omitted.

I don't buy it. It makes sense for a small company where the cost of fixing it might be noticed. But AMD generates some ~$30bn in annual revenues. How much of a developer's time does it take to change the code to use HTTPS? $1000? $5000? Let's be extreme and call it $10,000. That's 0.00003% of AMD's annual revenue. It's barely even a rounding error on their accounts.

You don’t believe it? It took until the early 2000s for Microsoft to take security seriously and they were a money printing machine.

I didn't say I don't believe it happens. I'm saying I don't believe it's a based on a cost benefit analysis. I.e. that in a multi-billion dollar company someone consciously ran the numbers and decided "it's cheaper for us to pay to clean up the mess if there's a security breach than it is to hire someone to fix security bugs". The cost of the latter is too low for this kind of logic to make any sense.

I think it's more realistic that in any sufficiently large company the bureaucracy is so unwieldy that sensible decisions become difficult to make and implement.

Re: The RCE that AMD won't fix

#126

Post by jbstack » Fri, Feb 06, 2026, 2:52 PM UTC

scott_w wrote: post #97

jbstack wrote: post #91

Earlier quoted context omitted.

I don't buy it. It makes sense for a small company where the cost of fixing it might be noticed. But AMD generates some ~$30bn in annual revenues. How much of a developer's time does it take to change the code to use HTTPS? $1000? $5000? Let's be extreme and call it $10,000. That's 0.00003% of AMD's annual revenue. It's barely even a rounding error on their accounts.

Because that's not how corporate maths works. The comparison is not "what is the cost of this vs our current revenue?" The calculation is "what could that engineer be doing instead and what is that worth vs fixing this issue?" Will fixing this issue bring in more revenue than ignoring it and building a new feature? Or fixing a different issue? If the answer is "no" then the answer is that it doesn't get fixed.

> The calculation is "what could that engineer be doing instead and what is that worth vs fixing this issue?"

I don't agree with this, because it pre-supposes that there's a limited number of engineers available. The question isn't "shall I pull engineer X off project Y so that he can fix security bugs?", it's "shall I hire an additional engineer to fix security bugs?". The comment above mine suggests the answer to that question is "no, because it's too expensive to do that compared to just paying to clean up security breaches after they happen", which is what I was questioning in my first comment.

Re: The RCE that AMD won't fix

#127

Post by tgsovlerkhgsel » Fri, Feb 06, 2026, 2:54 PM UTC

tptacek wrote: post #55

Hizonner wrote: post #52

Earlier quoted context omitted.

Apparently it's also outside the scope of their bug fixing program, despite being trivially remotely exploitable to get privileged code execution. Man in the middle attacks may be "out of scope" for AMD, but they're still "in scope" for actual attackers. Ignoring them is indefensibly incompetent. A policy of ignoring them is a policy of being indefensibly incompetent.

The only thing cited here is a response from their bug bounty program. Excluding MITM from a bug bounty is perfectly legitimate. Actually, excluding anything from a bounty program is.

Excluding severe vulnerabilities like ones that completely pwn your machine just by connecting it to an untrusted network is not legitimate for any reasonable bug bounty program.

Of course, a company can do it (they just did!), but it shows that they don't care about security at all.

Especially if the answer is "sorry this is out of scope" rather than "while this is out of scope for our bug bounty so we can't pay you, this looks serious and we'll make sure to get a patch out ASAP".

Re: The RCE that AMD won't fix

#128

Post by jbstack » Fri, Feb 06, 2026, 2:54 PM UTC

dgoldstein0 wrote: post #105

jbstack wrote: post #91

Earlier quoted context omitted.

I don't buy it. It makes sense for a small company where the cost of fixing it might be noticed. But AMD generates some ~$30bn in annual revenues. How much of a developer's time does it take to change the code to use HTTPS? $1000? $5000? Let's be extreme and call it $10,000. That's 0.00003% of AMD's annual revenue. It's barely even a rounding error on their accounts.

First they have to hire a developer with knowledge of how to do this right, as they might not even have one. Which could easily eat 10k+ of dev time as hiring good people takes a lot of time.

Ok, but this ultimately just comes down to a debate over the amount of the cost. The principle is the same. Even if we double or triple the cost, it's a drop in the ocean for a company like AMD.

Re: The RCE that AMD won't fix

#129

Post by tgsovlerkhgsel » Fri, Feb 06, 2026, 2:57 PM UTC

carefree-bob wrote: post #51

From the title, I thought this was going to be another one of those speculative execution information leakage bugs that are basically impossible to fix, but something this simple and easily fixable -- it's discouraging. Hopefully this decision is reversed. Also "Thank you for hacking our product" seems a bit unprofessional for someone engaging in responsible disclosure for a major security issue with your product.

"Thank you for hacking our product" sounds perfectly appropriate to me; it clearly uses "hacking" in the positive sense.

Re: The RCE that AMD won't fix

#130

Post by cestith » Fri, Feb 06, 2026, 3:01 PM UTC

thedanbob wrote: post #110

pmontra wrote: post #109

Earlier quoted context omitted.

If somebody is MITMing a target person, they will respond positively to "update available?" calls from that person and then serve the tainted update. The article does not say what the frequency of auto update check is. Let's say one per day. If somebody is targeted it's one day away from RCE.

The update check is HTTPS, only the files themselves are HTTP.

TLS doesn’t mask the IP of the server. The updater probably isn’t using DNS over HTTPS. If I can determine that a user’s updater just hit the update check server, I can start impersonating the update server.

That takes it out of the one day away territory, but it does allow an attacker to only have a malicious HTTP capture up and detectable during the actual attack window.

Then, of course, if you’re also being their DNS server you can send them to the wrong update check server in the first place. I wonder if the updater validates the certificate.