It sounds like compromising just 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 your new password is on a sticky-note, that's still a measurable improvement.
____________
Other scenarios:
* The victim's router settings are safe, but the attacker is on your LAN and uses DHCP spoofing to trick the target into using a different DNS server.
* The victim's LAN is safe, but the attacker set up a wireless network that spoofs another one the victim expects to see (coffee-shops, libraries, etc.) Or, heck, just one that reads "Free Wifi".
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 immediately own anyone with ATI graphics?
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 Development URL in production. While like the author said, even though the URL is using TLS/SSL so it's "safe", I would be curious to know if the executable URLs are the same in both XML files, and if not, I would perform binary diffing between those two executables.
I imagine there might be some interesting differential there that might lead to a bug bounty. For example, maybe some developer debug tooling that is only present only in the development version but is not safe to use for production and could lead to exploitation, and since they seemed to use the Development URL in production for some reason...
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.
This is the place they direct researchers to report bugs. If they don’t want to pay out for MITM, that’s fine, but they should still be taking out-of-scope reports seriously
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 network rather than rely upon AMD driver installer.
> This means that a malicious attacker on your network, or a nation state that has access to your ISP can easily perform a MITM attack and replace the network response with any malicious executable of their choosing.
http://www2.ati.com/...
I'm blocking port 80 since forever so there's that.
But now ati.com is going straight into my unbound DNS server's blocklist.
Based on the policy (and my hat) I have to assume some business partner failed to maintain the 'ca-certificates' equivalent for Windows (or NTP) and was rewarded in their insane demand for plaintext.
So easy to fix, just... why? My kingdom for an 's'. One of these policies are not like the others. Consider certificates and signatures before categorically turning a blind eye to MitM, please: you "let them in", AMD. Wow.
It sounds like compromising just 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 your new password is on a sticky-note, that's still a measurable improvement.
____________
Other scenarios:
* The victim's router settings are safe, but the attacker is on your LAN and uses DHCP spoofing to trick the target into using a different DNS server.
* The victim's LAN is safe, but the attacker set up a wireless network that spoofs another one the victim expects to see (coffee-shops, libraries, etc.) Or, heck, just one that reads "Free Wifi".
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 immediately own anyone with ATI graphics?
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 Development URL in production. While like the author said, even though the URL is using TLS/SSL so it's "safe", I would be curious to know if the executable URLs are the same in both XML files, and if not, I would perform binary diffing between those two executables.
I imagine there might be some interesting differential there that might lead to a bug bounty. For example, maybe some developer debug tooling that is only present only in the development version but is not safe to use for production and could lead to exploitation, and since they seemed to use the Development URL in production for some reason...
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.
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.
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.
This is the place they direct researchers to report bugs. If they don’t want to pay out for MITM, that’s fine, but they should still be taking out-of-scope reports seriously
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 network rather than rely upon AMD driver installer.
> This means that a malicious attacker on your network, or a nation state that has access to your ISP can easily perform a MITM attack and replace the network response with any malicious executable of their choosing.
I'm blocking port 80 since forever so there's that.But now ati.com is going straight into my unbound DNS server's blocklist.
Why even bother with WONTFIX? Turning on an nginx LetsEncrypt in front of it would have taken as long.
Based on the policy (and my hat) I have to assume some business partner failed to maintain the 'ca-certificates' equivalent for Windows (or NTP) and was rewarded in their insane demand for plaintext.
So easy to fix, just... why? My kingdom for an 's'. One of these policies are not like the others. Consider certificates and signatures before categorically turning a blind eye to MitM, please: you "let them in", AMD. Wow.
If this is true, it seems like a much more serious vulnerability than I was expecting when I clicked the link.
And it's obviously an oversight; there is no reason to intentionally opt for http over https in this situation.
>Attacks requiring physical access to a victim's computer/device, man in the middle or compromised user accounts
I love how they grouped man in the middle there