Hacker News Reader

Comment by pizlonator | Hacker News Reader

Weird how first the article downplays this because you supposedly need so much privilege to exploit this bug and then they point out that you need to have kernel privileges.

So that’s pretty bad. Kernel exploits aren’t that hard to find and it looks like this bug gives a path from kernel exploit to exploit persistence, with the only way to get rid of the persisted exploit is to throw away the CPU.

If I’m understand it right then, like, yikes!

View on HN

SMM shouldn't let you modify any persistent CPU-level state - SMM is slightly magic, but not that magic. It could absolutely allow modification of motherboard-level firmware, but that's repairable given enough enthusiasm.

Isn't the question whether a firmware / BIOS / microcode invasion is detectable given that the firmware has been taken over? The answer being probably not. Except for reading the flash memory at the chip level which is most likely not provided off the shelf by the system. To be repaired, the problem needs to be noticed first.

Platform Secure Boot will measure the firmware into the TPM, so if an attacker modifies the firmware then yes, it'll be detectable. The microcode is signed so any attempt to modify it will simply result in the CPU booting with its ROM-based microcode.

We'll get more detail tomorrow from Defcon - as to where the flaw is located. Apparently something in that neighborhood allows persistence - and for the attack not to be reported.

The shape of the flaw seems pretty clearly described in the abstract - it's the ability to either modify the contents of the locked SMM memory regions (and so get arbitrary code execution there), or trigger SMM execution of code outside the SMRAM region. Either way, SMM vulnerabilities aren't new, and the capabilities associated with them are pretty well understood - what's different here is that the vulnerability is apparently in the CPU rather than the firmware, and so everyone's affected no matter who their firmware vendor is.

SMM is merely a macguffin in this situation, it’s a tool to get the system into a privileged mode whereupon you buffer overflow it with a mailbox message or something. I’d really think that based on your username you have to already be aware of this?

Similar mechanisms were demoed in the ryzenfall exploit series like 5+ years ago.

https://youtu.be/QuqefIZrRWc?t=1195

You don't need to do that if you're able to just shove arbitrary code into SMM in the first place, which is what's supposedly happening here. But having SMM doesn't let you change any persistent CPU state - the set of additional privileges that SMM has is known, and basically comes down to "Can read and write SMRAM, trap certain hardware accesses, and write to protected areas of firmware flash". Nothing in SMM is going to allow you to backdoor the CPU itself so badly that you have to discard it.

SMM is implemented as part of the PSP (again, see the link in the previous comment) and yes, writing to protected areas of firmware flash is the point.

using SMM calls to jump to arbitrary code execution/control of the PSP is a big deal, that’s what happened before and probably what’s happened here.

You've got that the wrong way around - the PSP is able to access arbitrary areas of physical memory that can only otherwise be accessed via SMM, and so compromising the PSP gives you the ability to tamper with SMM code (as discussed in https://blog.trailofbits.com/2018/03/15/amd-flaws-technical-...). Having access to SMM doesn't give you access to the PSP, and being able to modify flash doesn't circumvent Platform Secure Boot. Power off the board and the CPU will return to exactly the state it left the factory in.

It's also unclear wether a virtualized guest can use this exploit. If so, it's a matter of hours until every cloud provider gets infected.

VMs generally don't have access to MSRs so they can't exploit this. Also, I would expect larger cloud providers have already patched.

Reply on news.ycombinator.com