> But even better, it has a security descriptor allowing Everyone + Low IL R/W Access, and an IOCTL interface with absolutely no Probes/SEH, which yes, dereferences wild pointers. They don't even bother checking for input size or output sizes.
If that's true of the driver, then it's a sec vuln regardless of what the MSR bit does or doesn't do, no?
That's a quote / follow up from the previous Twitter thread about how their driver does fucked things.
Absolutely a security vulnerability, and while I havent reproduced on my own and am just going off what I read on the original Twitter thread (so it's possible I could be regurgitating bad info), my understanding is that it gives processes this access by listening to process creation and hashing the name. Meaning if I have a known hash from the list I can simply rename my program / malware and bam.
Regardless, the vulnerability is in the driver, not the CPU / microcode. Also in the WHQL process that signed such a 'fake' driver. Until the signature is revoked, it might be possible for an attacker to manually install the signed driver on other system configurations too.
This hasn't gotten the attention it deserves. What this specific trick is doing is exploiting a bug Alex found in a driver called the "AMD PCI Driver". But what that driver actually does it check the process name vs. a dozen or so magic hash values (all games -- folks on twitter recovered most of them) and if found sets or clears a few bits in some undocumented MSRs that seemingly have something to do with the instruction cache. There's some thought that these are working around hardware bugs that only rare software triggers.
Needless to say, if Intel had played this trick it would have been pinned to the top of the front page here for the last week.
>Needless to say, if Intel had played this trick it would have been pinned to the top of the front page here for the last week.
Bit of a premature conjecture. It was on the first page when the hashes were uncovered some time ago.
I'm not trying to excuse problematic behaviour but when comparing apples to oranges one has to mention that AMD has an enormous, and complex, product stack and in total has one tenth the revenue of intel (most of which is earned by their CPU division) and Intel's graphics division mostly consists of homogenous integrated graphics solutions. Their graphics division was also a separate entity with their own team that struggled to make a profit and has been plagued with graphics driver issues for as long as I can remember.
Overall, their drivers have improved and I think things like this will reach their software engineering department. with all side channel attacks that have been uncovered the AMD CPU division has been hammering out security features and promoting their better security to cloud providers, so I think their attention will definitely be focused on not making graphics drivers their achilles heel.
To be clear: you're assuming hard work and good faith on the part of the developers, which I think is noble and probably well-founded. I'm talking about the clearly bad faith attempt to ship an obfuscated driver to presumably hide hardware bugs.
Still pretty hyperbolic. It's just as likely that these work around Intel-specific landmines that couldn't function anyway else without violating Intel's IP. Either way, it's a Windows + AMD driver thing, not baked into any Ryzen CPUs.
Your guess as what it works around is as good as mine, though.
You don't misname a performance hack or bug workaround or whatever this is as a "PCI Driver" by "incompetence" (quite literally it's got nothing to do with any device enumerable on the PCI buses -- it tweaks MSRs on the local CPU!). This was very clearly an attempt at obfuscation. We don't know why (or even what it does), but anyone can see what it is.
Though the core problem he's talking about is certainly notable. A sanctioned, signed, driver that exposes arbitrary kernel memory writes via ioctl() isn't great.
17 comments
[ 2.7 ms ] story [ 44.5 ms ] thread> But even better, it has a security descriptor allowing Everyone + Low IL R/W Access, and an IOCTL interface with absolutely no Probes/SEH, which yes, dereferences wild pointers. They don't even bother checking for input size or output sizes.
If that's true of the driver, then it's a sec vuln regardless of what the MSR bit does or doesn't do, no?
Absolutely a security vulnerability, and while I havent reproduced on my own and am just going off what I read on the original Twitter thread (so it's possible I could be regurgitating bad info), my understanding is that it gives processes this access by listening to process creation and hashing the name. Meaning if I have a known hash from the list I can simply rename my program / malware and bam.
https://twitter.com/aionescu/status/1393955460517040129
> * AMD Zen "Summit Ridge" Stepping B1. That is Ryzen's 1xxx series.
> * AMD Zen2 "Matisse", "XT" series only. That is Ryzen's 3xxx series.
Other info at:
https://twitter.com/aionescu/status/1394039410300051456 https://twitter.com/aionescu/status/1394359314102427650 https://twitter.com/aionescu/status/1394359317038452738
Regardless, the vulnerability is in the driver, not the CPU / microcode. Also in the WHQL process that signed such a 'fake' driver. Until the signature is revoked, it might be possible for an attacker to manually install the signed driver on other system configurations too.
I tried to install the NtObjectManager module, but Bitdefender blocked it as Gen:Variant.Ursu.903319
Attitude seems unnecessary though
Needless to say, if Intel had played this trick it would have been pinned to the top of the front page here for the last week.
Bit of a premature conjecture. It was on the first page when the hashes were uncovered some time ago.
I'm not trying to excuse problematic behaviour but when comparing apples to oranges one has to mention that AMD has an enormous, and complex, product stack and in total has one tenth the revenue of intel (most of which is earned by their CPU division) and Intel's graphics division mostly consists of homogenous integrated graphics solutions. Their graphics division was also a separate entity with their own team that struggled to make a profit and has been plagued with graphics driver issues for as long as I can remember.
Overall, their drivers have improved and I think things like this will reach their software engineering department. with all side channel attacks that have been uncovered the AMD CPU division has been hammering out security features and promoting their better security to cloud providers, so I think their attention will definitely be focused on not making graphics drivers their achilles heel.
Your guess as what it works around is as good as mine, though.
Though the core problem he's talking about is certainly notable. A sanctioned, signed, driver that exposes arbitrary kernel memory writes via ioctl() isn't great.
So it's not a vulnerability in Ryzen. Good.