Live data from Hacker News

The RCE that AMD won't fix

mrbruh.com

31–40 of 182 posts

Re: The RCE that AMD won't fix

#31
post #26
post #15

While I don't like that the executable's update URL is using just plain HTTP, AMD does explicitly state that in their program that attacks requiring man-in-the-middle or physical access is out-of-scope. Whether you agree with whether this rule should be out-of-scope or not is a separate issue. What I'm more curious about is the presence of both a Development and Production URL for their XML files, and their use of a…

> is a separate issue. No, just no. This is not a separate issue. It is 100% the issue. Lets say I'm a nation state attacker with resources. I write up my exploit and then do a BGP hijack of whatever IPs the driver host resolves to. There you go, I compromised possibly millions of hosts all at once. You think anyone cares that this wasn't AMDs issue at this point?

You misunderstand.

I already said I do not like that it is just using HTTP, and yes, it is problematic.

What I am saying is that the issue the author reported and the issue that AMD considers man-in-the-middle attacks as out-of-scope, are two separate issues.

If someone reports that a homeowner has the keys visibly on top of their mat in front of their front-door, and the homeowner replies that they do not consider intruders entering their home as a problem, these are two separate issues, with the latter having wider ramifications (since it would determine whether other methods and vectors of mitm attacks, besides the one the author of the post reported, are declared out-of-scope as well). But that doesn't mean the former issue is unimportant, it just means that it was already acknowledged, and the latter issue is what should be focused on (At least on AMD's side. It still presents a problem for users who disagree with AMD of it being out-of-scope).

Re: The RCE that AMD won't fix

#32
post #8

So compromising one DNS lookup is sufficient, ex: 1. Home router compromised, DHCP/DNS settings changed. 2. Report a wrong (malicious) IP for ww2.ati.com. 3. For HTTP traffic, it snoops and looks for opportunities to inject a malicious binary. 4. HTTPS traffic is passed through unchanged. __________ If anyone still has their home-router using the default admin password, consider this a little wake-up call: Even if yo…

It's usually very simple to get someone to join your malicious WiFi network with SSID spoofing, jamming, etc.

Re: The RCE that AMD won't fix

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

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

Re: The RCE that AMD won't fix

#34
post #31
post #26

Earlier quoted context omitted.

> is a separate issue. No, just no. This is not a separate issue. It is 100% the issue. Lets say I'm a nation state attacker with resources. I write up my exploit and then do a BGP hijack of whatever IPs the driver host resolves to. There you go, I compromised possibly millions of hosts all at once. You think anyone cares that this wasn't AMDs issue at this point?

You misunderstand. I already said I do not like that it is just using HTTP, and yes, it is problematic. What I am saying is that the issue the author reported and the issue that AMD considers man-in-the-middle attacks as out-of-scope, are two separate issues. If someone reports that a homeowner has the keys visibly on top of their mat in front of their front-door, and the homeowner replies that they do not consider i…

The phrasing of your first two sentences in your first post makes it sound like you're dismissing the security issue. For saying that it's a real security issue and then another issue on top you should word it very differently.

Re: The RCE that AMD won't fix

#36
post #30

Wow, this is an extremely serious vulnerability. People writing it off because it requires MitM. There's always a MitM, the internet is basically a MitM.

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

Re: The RCE that AMD won't fix

#37
post #18
post #16

Earlier quoted context omitted.

I don't expect an unbounded scope but I do expect it to cover the big scary headline items like RCE. Additionally, this can be exploited without MitM if you combine with e.g. a DNS cache poisoning attack. And they can still fix it even if they're not willing to pay a bounty.

DNS poisoning is a MITM vector; in fact, it's the most popular MITM vector.

Really? I thought MitM was always intercepting/manipulating traffic from or to the victim.

Re: The RCE that AMD won't fix

#39
AMD AutoUpdate terminal always pops up at midnight for me and then requires me to dismiss it. I've been meaning to uninstall this but always forget about it the next morning.

Now I have good reason to block it entirely and go back to manual updates

Re: The RCE that AMD won't fix

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

Is the issue in the OP related to windows? this wasn't immediately clear
Post reply on HN