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 hardware vendors
> 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 business it is likely much more important to bring the next hardware generation to the market as fast as possible.
In other words: distro maintainers and hardware vendors are simply interested in very different things and thus prioritize things very differently.
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.
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.
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.
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?
> 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.
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.
The risks continue, though:
* If the victim's router settings are safe, an attacker on the LAN may use DHCP spoofing to trick the target into using a different DNS server.
* The attacker can set up an alternate network they control, and trick the user into connecting, like for a real coffee shop, or even a vague "Free Wifi."
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.
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.
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
+1 Bounty aside, this deserves attention. I wouldn't want to award bounties for MitM either if I made it so easy. They closed the issue as 'out of scope'... with no mention of follow-up (or even the bounty we don't care about).
I'm skeptical to say the least. Industry standard has been to ignore MitM or certificates/signatures, not everything.
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.
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.
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...
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.
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).
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.
From the title, I thought this was going to be another one of those speculative execution information leakage bugs that are basically impossible to fix, but something this simple and easily fixable -- it's discouraging. Hopefully this decision is reversed. Also "Thank you for hacking our product" seems a bit unprofessional for someone engaging in responsible disclosure for a major security issue with your product.
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.
As someone that works security, the whole "A compromised DNS on the network" would be a total excuse not to pay.
The fact is allowing any type of unsigned update on HTTP is a security flaw in itself.
>someone would probably point out a much easier way to compromise the networ
No, not really. That's why every other application on the planet that does security of any kind uses either signed binaries or they use HTTPSONLY. Simply put allowing HTTP updates is insecure. The network should never be by default trusted by the user.
What's even fucking dumber on AMDs part is this is just one BGP hijacking from a worldwide security incident.
> The fact is allowing any type of unsigned update on HTTP is a security flaw in itself.
Reminds me about ten years or so ago when I was installing Debian or something and I noticed the URL for the apt install mirrors were http and not https. People helpfully pointed out this is a non issue because the updates are signed.
Ok I guess but then why did Debian switch to https?
Auto Update is EVERYTIME a RCE. When the software checks a signature, you just need the key. And the delivering enterprise have the key. EVERYTIME.
Don't understand why most people mean auto updating software would in any way create more security. It just creates more attack vectors for every software that has a auto updater.
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
How the hell is it possible that they're still using the ATI domain and HTTP 2026? They acquired ATI 20 fucking years ago.
It really makes you wonder what level of dysfunction is actually possible inside a company. 30k employees and they can't get one of them to hook up certbot, and add an 's' to the software.
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???
I do usually worry - because DNS spoofing is still possible and we are one step (eg: a compromised certificate) away from being pwned. But yeah one shouldn't have to worry.
I was in the shop for new PC today and decided on 9950x3d but I don't know how I opened HN just before the checkout and now I am a happy owner of intel 14900!
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.
No https:// and no cryptographic signature nor checksum that I can see. This makes it almost trivial for any nation-state to inject malware into targeted machines.
I removed AMD auto-update functionality from Windows boxen. (And I won't install anything similar on Linux.) And, besides, the Windows auto-update or check process hangs with a blank console window regularly.
Such trashy software ruins the OOBE of everything else. Small details attention zen philosophy and all that.
> 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.
> 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 am pretty sure, a nation state wanting to hack an individual's system has way more effective tools at their disposal.
I am pretty sure nation states hire people smart enough to use whatever works.
What the hell is more effective than getting root with a trivial MITM?
Not only is it effective, it's stealthy, in that it doesn't out you. It's obviously possible to both find and exploit it without a huge investment, which means nobody knows you're a nation state when you use it. You don't have to risk burning any really arcane zero-days or any hard to replace back doors.
Nation states are absolutely going to use things like that. And so is everybody else.
...such as talking directly to AMD or even Microsoft, which is scarier as Windows Updates are signed, and as long as they can be convinced to sign the right thing, it'll look even more legit.
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 hardware vendors
> 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 business it is likely much more important to bring the next hardware generation to the market as fast as possible.
In other words: distro maintainers and hardware vendors are simply interested in very different things and thus prioritize things very differently.
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
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.
You don't really need to run these updaters on windows.
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.
Linux has had support loading kernel modules since 1995.
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.
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?
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
This is oh sweet summer child stuff.
Have you ever gone to a crowded public place and setup an open hotspot?
Ah I think I never had to do connect to a public open hotspot because by the time I grew up 4G and then 5G internet were commonplace.
Never travelled to another country and needed internet before you could get a local sim working?
And you have them in your laptop? Or just using your phone and don't own a laptop at all?
> 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.
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 your new password is on a sticky-note, that's still a measurable improvement.
The risks continue, though:
* If the victim's router settings are safe, an attacker on the LAN may use DHCP spoofing to trick the target into using a different DNS server.
* The attacker can set up an alternate network they control, and trick the user into connecting, like for a real coffee shop, or even a vague "Free Wifi."
It's usually very simple to get someone to join your malicious WiFi network with SSID spoofing, jamming, etc.
Just spoofing a DNS reply would be enough if it arrives first, wouldn't it?
They're not considering it not to be a vulnerability. They're simply saying it's outside the scope of their bug bounty program.
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.
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.
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.
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.
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
+1 Bounty aside, this deserves attention. I wouldn't want to award bounties for MitM either if I made it so easy. They closed the issue as 'out of scope'... with no mention of follow-up (or even the bounty we don't care about).
I'm skeptical to say the least. Industry standard has been to ignore MitM or certificates/signatures, not everything.
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.
I wasn't agreeing with your example.
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.
That's still a MITM, albeit a LAN-local one. Non-LAN WAN isn't the total scope of MITMs.
That is a form of MiTM. It’s just changing DNS to IP bindings rather than IP to MAC or prefix to ISP.
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...
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.
> 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).
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.
From the title, I thought this was going to be another one of those speculative execution information leakage bugs that are basically impossible to fix, but something this simple and easily fixable -- it's discouraging. Hopefully this decision is reversed. Also "Thank you for hacking our product" seems a bit unprofessional for someone engaging in responsible disclosure for a major security issue with your product.
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.
As someone that works security, the whole "A compromised DNS on the network" would be a total excuse not to pay.
The fact is allowing any type of unsigned update on HTTP is a security flaw in itself.
>someone would probably point out a much easier way to compromise the networ
No, not really. That's why every other application on the planet that does security of any kind uses either signed binaries or they use HTTPSONLY. Simply put allowing HTTP updates is insecure. The network should never be by default trusted by the user.
What's even fucking dumber on AMDs part is this is just one BGP hijacking from a worldwide security incident.
> The fact is allowing any type of unsigned update on HTTP is a security flaw in itself.
Reminds me about ten years or so ago when I was installing Debian or something and I noticed the URL for the apt install mirrors were http and not https. People helpfully pointed out this is a non issue because the updates are signed.
Ok I guess but then why did Debian switch to https?
It really just requires a network that doesn't use some kind of NAC since you can trivially do ARP poisoning of your target.
Why even bother with WONTFIX? Turning on an nginx LetsEncrypt in front of it would have taken as long.
Auto Update is EVERYTIME a RCE. When the software checks a signature, you just need the key. And the delivering enterprise have the key. EVERYTIME.
Don't understand why most people mean auto updating software would in any way create more security. It just creates more attack vectors for every software that has a auto updater.
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
Omg that's what it is. I've been looking for DAYS.
How the hell is it possible that they're still using the ATI domain and HTTP 2026? They acquired ATI 20 fucking years ago.
It really makes you wonder what level of dysfunction is actually possible inside a company. 30k employees and they can't get one of them to hook up certbot, and add an 's' to the software.
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???
Many people don't worry about connecting to random wifi anymore, but users of AMD still have to
I do usually worry - because DNS spoofing is still possible and we are one step (eg: a compromised certificate) away from being pwned. But yeah one shouldn't have to worry.
I was in the shop for new PC today and decided on 9950x3d but I don't know how I opened HN just before the checkout and now I am a happy owner of intel 14900!
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.
This is unfortunate news but I'm not even surprised that they don't seem to care. Nice writeup.
Thanks for this, author.
No https:// and no cryptographic signature nor checksum that I can see. This makes it almost trivial for any nation-state to inject malware into targeted machines.
I removed AMD auto-update functionality from Windows boxen. (And I won't install anything similar on Linux.) And, besides, the Windows auto-update or check process hangs with a blank console window regularly.
Such trashy software ruins the OOBE of everything else. Small details attention zen philosophy and all that.
> 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.
>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
Spooky, this is not exposure if using Linux?
Of course not, the vulnerability is in "AMD’s AutoUpdate software" (i.e., vendor trash).
If you’re using Linux you’re almost certainly using your package manager to get any relevant updates.
> 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 am pretty sure, a nation state wanting to hack an individual's system has way more effective tools at their disposal.
Presumably, all Windows installations running on AMD are auto-executing this auto-update program.
I am pretty sure nation states hire people smart enough to use whatever works.
What the hell is more effective than getting root with a trivial MITM?
Not only is it effective, it's stealthy, in that it doesn't out you. It's obviously possible to both find and exploit it without a huge investment, which means nobody knows you're a nation state when you use it. You don't have to risk burning any really arcane zero-days or any hard to replace back doors.
Nation states are absolutely going to use things like that. And so is everybody else.
I guess one should keep their eyes out on the next big BGP hijack.
...such as talking directly to AMD or even Microsoft, which is scarier as Windows Updates are signed, and as long as they can be convinced to sign the right thing, it'll look even more legit.