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

101–110 of 182 posts

Re: The RCE that AMD won't fix

#101

Post by bravetraveler »

charcircuit wrote: post #60
digiown wrote: post #22

One good thing we can say about Linux bundling all the drivers is that it obviates the need to run almost all of this type of low quality (if not outright spyware) driver management software. They are especially problematic because they can't be sandboxed easily like most other proprietary crap. For whatever reason, distro maintainers working for free seem a lot more competent with security than billion dollar hardwa…

Linux has had support loading kernel modules since 1995.

modprobe http://192.168.1.1/amdgpu.ko

lol

Re: The RCE that AMD won't fix

#102

Post by ano-ther »

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

Re: The RCE that AMD won't fix

#103

Post by Avamander »

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 allowing it to fetch HTTP resources.

From my own perspective allowing unencrypted outgoing HTTP is a clear indication of problematic software. Even unencrypted (but maybe signed) CDN connections are at minimum a privacy leak. 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.

Re: The RCE that AMD won't fix

#104

Post by Avamander »

dns_snek wrote: post #90

Can anyone rationalize this decision? Sure technically this is outside the stated scope however the severity of this vulnerability is immediately obvious, which should trigger some alarm bells that the scope needs to be reconsidered. If they lose just one customer over this they're losing more than the minimum $500 bounty. They also signal to the world that they care more about some scope document than actually impro…

Honestly, even if it were in scope, just them getting paid is a bit odd given how AMD has been made aware of this multiple times over the years.

Re: The RCE that AMD won't fix

#105

Post by dgoldstein0 »

jbstack wrote: post #91
lloeki wrote: post #78

Earlier quoted context omitted.

It's a cost vs benefit. As long as the cost of such blatant violation of security principles doesn't outweight the benefit of focusing on something else, nothing is done. https://www.legalexaminer.com/lestaffer/legal/gm-recall-defe... https://www.youtube.com/watch?v=IA2EBWFCULg

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.

Re: The RCE that AMD won't fix

#106

Post by Avamander »

digiown wrote: post #33
colechristensen wrote: post #29

Earlier quoted context omitted.

It is, mostly, the organization Linus created (and of course the enormous number of people participating). An absurd amount of weight is carried by a small number of very influential people that can and want to just do a good job. And a signal that they're the best is you don't see them in the news. We need more very influential people who aren't newsworthy.

The most direct comparison would be the package manager, that's why I said distros. These driver management tools do a (poor) job at being a package manager, along with many other commercial software installation tools. With Linux itself, it helps that they are working in public (whether volunteering or as a job), and you'd be sacked not in a closed-door meeting, but on LKML for everyone to see if you screw up this b…

Popular Linux distributions also use HTTP CDNs. Even though the content is always signed, it still exposes the HTTP stack, signature verification code and a bunch of the application logic to the attacker.

Apt has had issues where captive portals corrupt things. GPG has had tons of vulnerabilities in signature verification (but to be fair here, Apt is being migrated to Sequoia, which is way better).

But these distros are still exposing a much larger attack surface compared to just a TLS stack.

Re: The RCE that AMD won't fix

#107

Post by Someone »

FTA: “Therefore I will have to close the report as out of scope”

and “05/02/2026 - Report Closed as wont fix/out of scope”

I think it’s a bit early to say “won’t fix”. AMD only said that it was out of scope for the channel used to report it (I don’t know what that was, but it likely is a bug bounty program) and it’s one day after the issue was reported to them.

Re: The RCE that AMD won't fix

#108

Post by TekMol »

Even though the software might have been written by AMD, I think there is at least one more party to blame.

Who has put that software on the PC in the first place?

Was it the manufacturer?

Or was it Microsoft via Windows?

Re: The RCE that AMD won't fix

#109

Post by pmontra »

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

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.

Re: The RCE that AMD won't fix

#110

Post by thedanbob »

pmontra wrote: post #109
ano-ther wrote: post #102

Earlier quoted context omitted.

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

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.
Post reply on HN