zlacker

>>zdw+(OP)
People like to criticize secure boot around here, but it prevents these kinds of infections (provided of course there are no vulnerabilities in the implementation of secure boot).

Yes, in theory it is possible to prevent these kinds of infections without resorting to secure boot (e.g., by insisting that all the suppliers of components of the motherboard start designing components that cannot be pwned) but so far all the computers you have actually been able to buy that are immune to these kinds of infections achieve that immunity with secure-boot technology.

>>holler+eTa
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+TWa
> 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.