5 ms·

Crash a Ryzen system in single line of tweetable PowerShell

50 points by simon04 5y ago

danparsonson 5y ago
Lots of replies saying 'unable to reproduce' for various different Ryzens, so I don't think this is all it's made out to be.
- danarmak 5y ago
  He also says, > 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?
  - Perolan 5y ago
    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.
- danarmak 5y ago
  He posted again later clarifying which systems and configuration were vulnerable: https://twitter.com/aionescu/status/1393955460517040129 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/1394039410300051456 https://twitter.com/aionescu/status/1394359314102427650 https://twitter.com/aionescu/status/1394359314102427650 https://twitter.com/aionescu/status/1394359317038452738 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.
- vince14 5y ago
  Because they can't read and are missing a module.
- zeeZ 5y ago
  From the screenshots they post it looks like they're missing a powershell module that's not built-in. I tried to install the NtObjectManager module, but Bitdefender blocked it as Gen:Variant.Ursu.903319
nebulous1 5y ago
This is interesting and also makes me want to look at powershell a bit more. Attitude seems unnecessary though
perryizgr8 5y ago
So if you run malicious code on your PC it can cause problems? Huh...
tyingq 5y ago
"Single line of", as usual, is a bit overstated in the headline. One line of PowerShell plus an installed suite of powershell tools from Google's project Zero: https://github.com/googleprojectzero/sandbox-attacksurface-analysis-tools https://github.com/googleprojectzero/sandbox-attacksurface-a.... 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.
ajross 5y ago
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.
- Out_of_Characte 5y ago
  >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.
  - ajross 5y ago
    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.
    - 5y ago
g00s3_caLL_x2 5y ago
I hope he at least tried to inform the manufacturer responsibly before trying to pat his own back.
johnklos 5y ago
The title is a bit click-baity. Obviously this is a Windows-specific issue, and obviously it only happens when you install the AMD software. So it's not a vulnerability in Ryzen. Good.

50 points by simon04 5y ago

Lots of replies saying 'unable to reproduce' for various different Ryzens, so I don't think this is all it's made out to be.

danarmak 5y ago
He also says, > 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?
- Perolan 5y ago
  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.
danarmak 5y ago
He posted again later clarifying which systems and configuration were vulnerable: https://twitter.com/aionescu/status/1393955460517040129 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/1394039410300051456 https://twitter.com/aionescu/status/1394359314102427650 https://twitter.com/aionescu/status/1394359314102427650 https://twitter.com/aionescu/status/1394359317038452738 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.
vince14 5y ago
Because they can't read and are missing a module.
zeeZ 5y ago
From the screenshots they post it looks like they're missing a powershell module that's not built-in. I tried to install the NtObjectManager module, but Bitdefender blocked it as Gen:Variant.Ursu.903319

nebulous1 5y ago

This is interesting and also makes me want to look at powershell a bit more. Attitude seems unnecessary though

perryizgr8 5y ago

So if you run malicious code on your PC it can cause problems? Huh...

tyingq 5y ago

"Single line of", as usual, is a bit overstated in the headline. One line of PowerShell plus an installed suite of powershell tools from Google's project Zero: https://github.com/googleprojectzero/sandbox-attacksurface-analysis-tools https://github.com/googleprojectzero/sandbox-attacksurface-a.... 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.

ajross 5y ago

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.

Out_of_Characte 5y ago
>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.
- ajross 5y ago
  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.
  - 5y ago

g00s3_caLL_x2 5y ago

I hope he at least tried to inform the manufacturer responsibly before trying to pat his own back.

johnklos 5y ago

The title is a bit click-baity. Obviously this is a Windows-specific issue, and obviously it only happens when you install the AMD software. So it's not a vulnerability in Ryzen. Good.