I am pretty sure, a nation state wanting to hack an individual's system has way more effective tools at their disposal.
The RCE that AMD won't fix
21–30 of 182 posts
Re: The RCE that AMD won't fix
#22For whatever reason, distro maintainers working for free seem a lot more competent with security than billion dollar hardware vendors
Re: The RCE that AMD won't fix
#23Why even bother with WONTFIX? Turning on an nginx LetsEncrypt in front of it would have taken as long.
Re: The RCE that AMD won't fix
#24It'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…
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.
Re: The RCE that AMD won't fix
#25> 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.
Re: The RCE that AMD won't fix
#26While 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…
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?
Re: The RCE that AMD won't fix
#27> 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.
Re: The RCE that AMD won't fix
#28One 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…
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.
Re: The RCE that AMD won't fix
#29One 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…
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.