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

71–80 of 182 posts

Re: The RCE that AMD won't fix

#71

Post by atq2119 »

Retr0id wrote: post #12
tptacek wrote: post #10

They're not considering it not to be a vulnerability. They're simply saying it's outside the scope of their bug bounty program.

Looks like there's a serious security bug in their scope document.

If you read it carefully, you'll notice that the blog post misrepresents the AMD response.

The blog post title is "AMD won't fix", but the actual response that is quoted in the post doesn't actually say that! It doesn't say anything about will or won't fix, it just says "out of scope", and it's pretty reasonable to interpret this as "out of scope for receiving a bug bounty".

It's pretty careless wording on the part of whoever wrote the response and just invites this kind of PR disaster, but on the substance of the vulnerability it doesn't suggest a problem.

Re: The RCE that AMD won't fix

#72

Post by rtpg »

dbtablesorrows wrote: post #65
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…

Who would connect to unknown person's hotspot? But it seems pretty trivial for some bad actor at local ISP.

> Who would connect to unknown person's hotspot?

SSID "Sydney Airport Wifi" or the like.

Re: The RCE that AMD won't fix

#73

Post by jimrandomh »

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 still get a news cycle.

The threat model here is that compromised or malicious wifi hotspots (and ISPs) exist that will monitor all unencrypted traffic, look for anything being downloaded that's an executable, and inject malware into it. That would compromise a machine that ran this updater even if the malware wasn't specifically looking for this AMD driver vulnerability, and would have already compromised a lot of laptops in the past.

Re: The RCE that AMD won't fix

#74

Post by Kodiack »

hulitu wrote: post #63
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…

> Like couldn't you just sit in an airport and open up a wifi hotspot and almost immediately own anyone with ATI graphics? Some of us do not enable automatic updates (automatic updates are the peak of stupidity since Win98 era). And, when you sit in an airport, you don't update all your programs.

Automatic updates are absolutely not peak stupidity. Most users’ devices would have nasty security vulnerabilities wide open for a much longer period of time without automatic updates.

Re: The RCE that AMD won't fix

#75

Post by dbtablesorrows »

rtpg wrote: post #72
dbtablesorrows wrote: post #65

Earlier quoted context omitted.

Who would connect to unknown person's hotspot? But it seems pretty trivial for some bad actor at local ISP.

> Who would connect to unknown person's hotspot? SSID "Sydney Airport Wifi" or the like.

You're more [security minded](https://www.schneier.com/blog/archives/2008/03/the_security_...) than me

Re: The RCE that AMD won't fix

#76

Post by gusgus01 »

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.

The response from the screenshot appears to be a "out of scope" response, but the blog poster used some editorial leeway and called it "wont fix/out of scope". Going forward, we can keep de-compiling and seeing if this vulnerability is still there and whether "wont fix" was a valid editorialization.

Though, by publishing this blog and getting on the HN front page, it really skews this datapoint, so we can never know if it's a valid editorialization.

Edit: Ah, someone else in this thread called out the "wont fix" vs "out of scope" after I clicked on reply: https://news.ycombinator.com/item?id=46910233. Sorry.

Re: The RCE that AMD won't fix

#77

Post by rcxdude »

b1temy wrote: 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…

For paying out, maybe, but this is 100% a high priority security issue regardless of AMD's definition of in scope, and yet because they won't pay out for it they also seem to have decided not to fix it.

Re: The RCE that AMD won't fix

#78

Post by lloeki »

da_chicken wrote: post #43
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…

Sure. New sales means new revenue. Maintenance and support is just overhead. It's shortsighted, but modern capitalism is more shortsighted than Mr. Magoo.

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

Re: The RCE that AMD won't fix

#79

Post by pooper »

nextaccountic wrote: post #40
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…

Is the issue in the OP related to windows? this wasn't immediately clear

Yes, because you would only run such an updater software on Windows.
Post reply on HN