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

111–120 of 182 posts

Re: The RCE that AMD won't fix

#111

Post by Symmetry »

aleph_minus_one wrote: post #28
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…

> 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 incompetent with security.

Re: The RCE that AMD won't fix

#113

Post by r1ch »

jimrandomh wrote: post #73

If this is as described, it's a pretty major failure of security-vulnerability report triage, and rises to the level where security departments at major corporations will be having meetings about whether they want to ban AMD hardware from their organizations entirely, or only ban the AMD update application. If this had gone the "brand name and a scored CVE" route, it would probably have gotten a news cycle. It might…

Anyone can request a CVE, this is sadly the most likely path towards getting it fixed.

Re: The RCE that AMD won't fix

#114

Post by bflesch »

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…

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.

Re: The RCE that AMD won't fix

#116

Post by Ginden »

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

You need only a device on network to spam DHCP messages with malware DNS. So you don't need "shady hotspot", only compromised device within network.

Re: The RCE that AMD won't fix

#117

Post by myst »

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…

The corporate drones have the management tower above them, the OSS enthusiasts do not. That is it.

Re: The RCE that AMD won't fix

#118

Post by arghwhat »

bflesch wrote: post #114
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…

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.

Re: The RCE that AMD won't fix

#119

Post by arghwhat »

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 less trustworthy than the many TLS and HTTP libraries out there.

Re: The RCE that AMD won't fix

#120

Post by zeendo »

aleph_minus_one wrote: post #28
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…

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

This comes down to intentions versus results. Viewed through the lens of results the comment you're replying to is still correct: The result is incompetence. I'd argue that's the only lens that matters when you're on the receiving end of such work.
Post reply on HN