Live data from Hacker News

The RCE that AMD won't fix

mrbruh.com

41–50 of 182 posts

Re: The RCE that AMD won't fix

#41
post #18

Earlier quoted context omitted.

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.

What you wrote is the definition of MITM.

Op and others are saying DNS poisoning is a popular way of achieving that goal.

Re: The RCE that AMD won't fix

#42
post #31

Earlier quoted context omitted.

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.

> The phrasing of your first two sentences in your first post makes it sound like you're dismissing the security issue.

Genuine question, How does it sound like I'm dismissing it? My first sentence begins with the the phrase

> I don't like that the executable's update URL is using just plain HTTP

And my second sentence

> Whether you agree with whether this rule should be out-of-scope or not is a separate issue.

which, with context that AMD reported MITM as out-of-scope, clearly indicates that I think of it as an issue, albeit, a separate one from the one the author already reported.

Re: The RCE that AMD won't fix

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

Sure. New sales means new revenue. Maintenance and support is just overhead.

It's shortsighted, but modern capitalism is more shortsighted than Mr. Magoo.

Re: The RCE that AMD won't fix

#44
post #14
post #12

Earlier quoted context omitted.

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

How's that? What do you think the purpose of a bug bounty is? If you think it's "to eradicate all bugs", no, very no.

A bug bounty should motivate exploitable bugs to be reported so that they can be fixed. IMO, if it refuses to accept certain kinds of bugs that can still be exploited, it's not working properly.

Re: The RCE that AMD won't fix

#45
post #14

Earlier quoted context omitted.

How's that? What do you think the purpose of a bug bounty is? If you think it's "to eradicate all bugs", no, very no.

A bug bounty should motivate exploitable bugs to be reported so that they can be fixed. IMO, if it refuses to accept certain kinds of bugs that can still be exploited, it's not working properly.

A bug bounty directs internal engineering efforts. It can't eradicate bugs; that's not how bugs work.

Re: The RCE that AMD won't fix

#47

Earlier quoted context omitted.

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

What you wrote is the definition of MITM. Op and others are saying DNS poisoning is a popular way of achieving that goal.

Oh you mean that it's a popular way of initiating the interception part of MitM, got it.

Re: The RCE that AMD won't fix

#48
post #11

It's not directly an RCE unto itself, it requires something else. A compromised DNS on the network, e.g. So no surprise they ignored it. Also, if AMD is getting overwhelmed with security reports (a la curl), it's also not surprising. Particularly if people are using AI to turn bug bounties into income. Lastly if it requires a compromised DNS server, someone would probably point out a much easier way to compromise the…

It really just requires a network that doesn't use some kind of NAC since you can trivially do ARP poisoning of your target.

Re: The RCE that AMD won't fix

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

Just spoofing a DNS reply would be enough if it arrives first, wouldn't it?

Re: The RCE that AMD won't fix

#50
Marking this as a WONTFIX should have gotten somebody fired at AMD. I find it hard to believe that at least one of their VPs doesn't frequent this site.

I don't normally call for people to get fired from their jobs, but this is so disgusting to anyone who takes even a modicum of pride in their contribution to society.

Surely, someone gets fired for dismissing a legitimate, easily exploited RCE using a simple plaintext HTTP MITM attack as a WONTFIX... Right???

Post reply on HN