zlacker

Can you please explain how Secure Boot helps at all to mitigate this type of attack? I don’t see how it makes it harder to execute the attack, and I don’t see how it has any particular effect on the capabilities of the attack once executed. To the contrary, a BMC compromise of this sort seems like it should be able to arbitrarily override secure boot settings.

It seems to me that, in this situation, secure boot’s only role is to provide a false sense of security, which could make recovery from the attack less likely.

In contrast, verified boot might somewhat mitigate the damage from being able to use the BMC to write arbitrary data to the SPI flash chip. Emphasis on might — at best I expect that it would require an attacker to be a bit more creative in how they design their exploit payload.

>>amluto+(OP)
I have never seen someone make a distinction between Secure Boot and boot verification on UEFI/x86, although I suppose it’s a valid one? I suspect the parent post is referring to Secure Boot in the colloquial sense it’s usually used for on x86: validation of the UEFI boot binary using Secure Boot keys followed by OS level trust chaining, usually accomplished by entangling PCR state with disk encryption in some way.

And I think this would deliver a slight level of protection from the BMC: tampering with the firmware image or key enrollment / secure boot state _should_ both break the UEFI root of trust and alter the PCR state and break everything downstream. Of course, all UEFI implementations are holier than Swiss cheese and there are probably a lot of ways to use the BMC to dump or modify memory post-boot anyway, but it does do something.

>>bri3d+l8
You mean the same Secure Boot that I mean. This is a software mechanism (almost universally implemented as an unholy mixture of ordinary code in firmware and a pile of immensely complex SMM code that, IMO, is entirely unnecessary if the hardware or the BMC gives even the slightest bit of help).

And Secure Boot is implemented in, and configured by, the firmware that the BMC can overwrite at its whim while entirely bypassing all the fancy CPU-hardware and SMM protections that are supposed to prevent writing arbitrary data to it.

To the extent that a mechanism not controlled by firmware will detect such an attack and extend PCRs accordingly before executing a single instruction from the compromised flash chip, it might partially mitigate attacks. But that part isn’t Secure Boot.

>>amluto+Ng
Oh, yes, we 100% agree on this, the true root of trust for firmware execution exists before and independently of “secure boot,” and therefore, often not at all (and “secure boot” is a terrible name).

>>amluto+(OP)
> Can you please explain how Secure Boot helps at all to mitigate this type of attack?

Secure boot can include the hash of the firmware, computed by the root-of-trust that can't be tampered with by this attack. So the exploit will make the keys stored in the TPM inaccessible.

This will make the tampering conspicuous, at least.

>>cybera+LB
I agree in general; PCRs provide some basic degree of protection against this. Unfortunately, the position these management controllers are in often grants memory access, which renders all of the boot measurement type security methods useless. Even if it doesn't, there's also the notion that an attacker will replace the firmware from the very start with one that fakes the PCR hashes which are sent to the TPM. Unfortunately, this isn't really very hard with most UEFI implementations.