[deleted]
The RCE that AMD wouldn't fix
51–60 of 131 posts
Re: The RCE that AMD wouldn't fix
#52It's ridiculous to consider MITM attacks out of scope for taking over your computer. Also, there are probably ways to exploit this without a true MITM like DNS cache poisoning. But it's best to just assume the whole internet is MITMed.
Why would anyone ever exclude true mitm? Various domain registrars have been compromised over and over again (often by children!), resulting in companies like Tesla and Cloudflare getting owned. The reality is that any vaguely competent attacker can compromise a court clerk and just compel e.g. the .com registry to hand over whatever domain they want. Although I suppose the aforementioned problem has significant impl…
>Why would anyone ever exclude true mitm?
Same reason security programs exclude social engineering, even though that's a pretty common way for companies to get pwned.
Re: The RCE that AMD wouldn't fix
#53Earlier quoted context omitted.
MITM where attacker needs to install their own CA certs on the victim's device -- sure, out of scope. MITM because you used http instead of https and you don't have any other verified cryptographic signature on your data -- get tae fuck, fix it pronto.
I'd even count this as "having local access to the device", as that is what is needed to install such a cert
I think it's fair to say that requiring local administrative access to the device is out of scope, since you have already completely pwned the device in that case, which is what what you need to install a CA cert on any OSes.
Re: The RCE that AMD wouldn't fix
#54Multi billion dollar company, by the way.
Re: The RCE that AMD wouldn't fix
#55It's ridiculous to consider MITM attacks out of scope for taking over your computer. Also, there are probably ways to exploit this without a true MITM like DNS cache poisoning. But it's best to just assume the whole internet is MITMed.
Out of scope in this case means "we don't wanna pay you"
Apparently it also means "We don't want to pay our engineers to fix this".
Re: The RCE that AMD wouldn't fix
#56Earlier quoted context omitted.
Why would anyone ever exclude true mitm? Various domain registrars have been compromised over and over again (often by children!), resulting in companies like Tesla and Cloudflare getting owned. The reality is that any vaguely competent attacker can compromise a court clerk and just compel e.g. the .com registry to hand over whatever domain they want. Although I suppose the aforementioned problem has significant impl…
>Why would anyone ever exclude true mitm? Same reason security programs exclude social engineering, even though that's a pretty common way for companies to get pwned.
Excluding SE is to make sure people do not spam customer support and launch annoying phishing campaigns. None of that is applicable for local software running on your own computer.
Re: The RCE that AMD wouldn't fix
#57The "signature verification" in the fix being CRC32 is pretty hilariously clueless.
It's technically possible (though I don't know if they actually do this) that they're not referring to a signature check in the download part, but are verifying the code signing signature of the executable downloaded. You'd only notice the CRC if you were looking at the downloaded content, but if the updater refuses to launch an executable that isn't signed by AMD's cert then they would be fine. Given the way AMD has…
The article has a screenshot of the decompiled code showing that they're just running the downloaded executable immediately, without any additional checks on the content.
Re: The RCE that AMD wouldn't fix
#58AMD's utter incompetence when it comes to the software side of things is truly, truly baffling to me. It's not like you need a mountain of developers, a team or two on the right project would do wonders for their market share. For example: Implement the CUDA. CUDA's won, hands down, that toothpaste is solidly outside the tube. Luckily, to the outside observer CUDA is just an API, and API's aren't copyrightable. Liter…
likewise. i'm bewildered throughout the years.
my suspicion is that it is the company culture: the hardware engineers are the real engineers. software is a triviality left for the lesser minds. the consequence is they mess up every product... everything they do needs software.
Re: The RCE that AMD wouldn't fix
#59AMD's utter incompetence when it comes to the software side of things is truly, truly baffling to me. It's not like you need a mountain of developers, a team or two on the right project would do wonders for their market share. For example: Implement the CUDA. CUDA's won, hands down, that toothpaste is solidly outside the tube. Luckily, to the outside observer CUDA is just an API, and API's aren't copyrightable. Liter…
likewise. i'm bewildered throughout the years. my suspicion is that it is the company culture: the hardware engineers are the real engineers. software is a triviality left for the lesser minds. the consequence is they mess up every product... everything they do needs software.
The argument I have read here on HN, is that CUDA is made for NVidia hardware, and the AMD hardware is not the best fit.
Essentially it forces AMD to play by NVidias rules, exactly like how they were forced to follow Intel rules. (Ignore for a second that the API / ISA boundary is different.)
But despite that, I also believe AMD would be better off just implementing CUDA.
Re: The RCE that AMD wouldn't fix
#60AMD's utter incompetence when it comes to the software side of things is truly, truly baffling to me. It's not like you need a mountain of developers, a team or two on the right project would do wonders for their market share. For example: Implement the CUDA. CUDA's won, hands down, that toothpaste is solidly outside the tube. Luckily, to the outside observer CUDA is just an API, and API's aren't copyrightable. Liter…
HIP tries to be like this, almost API compatible with CUDA such that you just need to do find and replace. I think they even had a script to do this for you.
But the issue remains that the actual support and debugging tools remain so atrocious that it doesn't help to combat the CUDA monopoly. They've further burned a lot of trust by never really delivering on their promises to do better unless you're a customer large enough to get personalized attention from their engineers.
This ends up being a double whammy because not only are you pushing away smaller businesses, you're also pushing away single developers that go on to influence purchasing/development decisions.