Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The RCE that AMD won't fix

mrbruh.com

Post reply on HN
Print view View original

151–160 of 182 posts

Re: The RCE that AMD won't fix

#151

Post by ramon156 »

rtpg wrote: post #3

This is super bad right? Like anybody who has this running will be vulnerable to a super basic HTTP redirect -> installer running on their machine attack, right? And on top of that it's for something that is likely installed on _so many_ machines, right? I don't think I've ever seen something this exploitable that is so prevalent. Like couldn't you just sit in an airport and open up a wifi hotspot and almost immediat…

You can get arrested for this in my country, fun fact.

I guess that's how you prevent anything, just make it illegal and the exploit becomes an unintended illegal feature, like occupying the low-freq radio signal.

Re: The RCE that AMD won't fix

#152

Post by Avamander »

vladvasiliu wrote: post #138
inetknght wrote: post #131

Earlier quoted context omitted.

> For signed payloads there is no difference, you're trusting 's authentication code to read a blob, a signature and validate it according to a public key. Assuming this all came through unencrypted HTTP: - you're also trusting that the client's HTTP stack is parsing HTTP content correctly - for that matter, you're also trusting that the server (and any man-in-the-middle) is generating valid HTTP responses - you're a…

If you don't trust the http client to not do something stupid, this all applies for https, too. Plus, they can also bork on the ssl verification phase, or skip it altogether.

TLS stacks are generally significantly harder targets than HTTP ones. It's absolutely possible to use one incorrectly, but then we should also count all the ways you can misuse a HTTP, there are a lot more of those.

Re: The RCE that AMD won't fix

#153

Post by Avamander »

yrro wrote: post #124
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?

Nothing really cares except like Prusa Connect.

Re: The RCE that AMD won't fix

#154

Post by Avamander »

arghwhat wrote: post #118
bflesch wrote: post #114

Earlier quoted context omitted.

AFAIK a lot of linux packet repositories are http-only as well. Convenient for tracking what package versions have been installed on a certain system.

They usually support both, but important to note that HTTPS is only used for privacy. Package managers generally enforce authenticity through signed indexes and (directly or indirectly) signed packages, although be skeptical when dealing with new/minor package managers as they could have gotten this wrong.

Reducing the benefit of HTTPS to only privacy is dishonest. The difference in attack surface exposed to a MITM is drastic, TLS leaves so little available for any attacker to play with.

Re: The RCE that AMD won't fix

#155

Post by autoexec »

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.

You could probably take any user at random from this discussion alone and they'd have the knowledge needed to make the switch from http to https. I'm certain that AMD has all the knowledge they need right now, but even more certain that it wouldn't be hard to hire someone new who does as well

Re: The RCE that AMD won't fix

#156

Post by rtpg »

ano-ther wrote: post #102
rtpg wrote: post #3

This is super bad right? Like anybody who has this running will be vulnerable to a super basic HTTP redirect -> installer running on their machine attack, right? And on top of that it's for something that is likely installed on _so many_ machines, right? I don't think I've ever seen something this exploitable that is so prevalent. Like couldn't you just sit in an airport and open up a wifi hotspot and almost immediat…

Not that this isn’t bad, doesn’t this only apply when an update is available? So you have to be on a shady hotspot, without VPN, AMD has recently published an update, and your update scheduler is timed to run. That would be a little less than “immediately own anyone with ATI”.

Oh yeah fair point, the HTTPS-ness of the first step is a helpful backstop

Re: The RCE that AMD won't fix

#157

Post by Avamander »

arghwhat wrote: post #119
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…

> Potentially it's even a way for a MITM to exploit the HTTP stack, some content parser or the application's own handling. TLS stacks are a significantly harder target in comparison. For signed payloads there is no difference, you're trusting 's authentication code to read a blob, a signature and validate it according to a public key. For package managers that usually only mean trusting gpg - at the very least no les…

There's a massive difference. The entire HTTP stack comes into play before whatever blob is processed. GPG is notoriously shitty at verifying signatures correctly. Only with the latest Apt there's some hope that Sequoia isn't as vulnerable.

In comparison, even OpenSSL is a really difficult target, it'd be massive news if you succeed. Not so much for GPG. There are even verified TLS implementations if you want to go that far. PGP implementations barely compare.

Fundamentally TLS is also tremendously more trustworthy (formally!) than anything PGP. There is no good reason to keep exposing it all to potential middlemen except just TLS. There have been real bugs with captive portals unintentionally causing issues for Apt. It's such an _unnecessary_ risk.

TLS leaves any MITM very little to play with in comparison.

Re: The RCE that AMD won't fix

#158

Post by scott_w »

jbstack wrote: post #143
scott_w wrote: post #141

Earlier quoted context omitted.

It doesn't matter: the equation is exactly the same. Why would you hire someone to work on a bug fix or security fix when you could hire that same person and have them work on something even more valuable again?

Now there's a related problem in the premise: it pre-supposes that the company has an unlimited amount of valuable work to be done. If that were the case, all companies would simply expand their workforce as much as possible all the time, only constrained by money running out (which itself would be an exponential increase since "valuable" work presumably leads to more money in future). In reality, companies do not pr…

> it pre-supposes that the company has an unlimited amount of valuable work to be done.

In effect, there is, yes. At the very least, there’s more high value work that most companies can do than there are engineers to do said work. There’s a reason literally every leadership course teaches you how to say “no” over and over again.

Re: The RCE that AMD won't fix

#159

Post by scott_w »

lencastre wrote: post #148
scott_w wrote: post #97

Earlier quoted context omitted.

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.

ah corporate meff, if the claim is lower than the recall cost, pay the claim

You can complain all you want about it but, unless you can push up the cost of the claim, that’s what corporations will do.

Re: The RCE that AMD won't fix

#160

Post by fulafel »

burnt-resistor wrote: post #57
webstrand wrote: post #36

Earlier quoted context omitted.

MitM isn't even necessary, a rogue DHCP server configuring a malicious DNS could attack this.

That's still a MITM, albeit a LAN-local one. Non-LAN WAN isn't the total scope of MITMs.

If my computer asks your computer what dns server to use, and you respond with the address of a nefarious one, it's not necessarily a mitm.
Post reply on HN