4 ms·

Or just Secure Boot (on the BMCs).

by moonbug 8y ago

asaph 8y ago
How does this defend against a the type of hardware-based attack discussed in the article?
- rjst01 8y ago
  The same way secure-boot provides protection against hardware modification / evil maid type attacks in CPUs today: by verifying the integrity of the code that's about to be booted before the CPU boots it. It would significantly raise the cost and difficulty of this sort of attack.
  - wolfgke 8y ago
    > It would significantly raise the cost and difficulty of this sort of attack. In my opinion, modifying the board layout with the additional chip and modifying the production process for the server boards stealthily already has a pretty high cost and difficulty.
    - rjst01 8y ago
      > already has a pretty high cost and difficulty That's true, but properly implemented secure boot could serve to increase it by an order of magnitude.
- monocasa 8y ago
  The best guess I've heard is that this attack pulls down the BMC's SPI flash lines in order to corrupt its code as it's loaded. A proper chain of trust that starts on the BMC chip could absolutely protect against that. At that point any modification to the boot image would leave the BMC refusing to boot rather giving attacker control.
subudeepak 8y ago
Hardware attacks cannot be prevented by secure boot...
- wolfgke 8y ago
  > Hardware attacks cannot be prevented by secure boot... But by Trusted Computing (at least in some implementations).
- moonbug 8y ago
  The most plausible hypothesis of how this attack works is by corrupting firmware loaded at power-on time over SPI. Secure boot would absolutely protect from that by rejecting the signature of the modified code. By hey, I get that Newsy groupthink means secure boot bad.
  - subudeepak 8y ago
    Secure boot is in no way bad :-) Ofcourse, it must in fact be the first point on any sane security checklist. And one of the most common attacks aka. malicious firmware is prevented by using secure boot. Many other classes of attacks like forcing the microcontroller to delete all its data, opening up the debug JTAG port of the microcontroller, preventing the log of certain security events etc. can be achieved with the right settings. Though these are just remote possibilities with high levels of complexity, so is changing a production design of a board.
  - asdf2341234 8y ago
    >is by corrupting firmware loaded at power-on time over SPI. >Secure boot would absolutely protect from that by rejecting the signature of the modified code. Why couldn't you also change out the keys so the signature does match?
    - moonbug 8y ago
      Doing so means compromising the TPM on the BMC module which is much harder to do. It's not something that can be done downstream in the supply chain, as this attack is purported to have been.

Or just Secure Boot (on the BMCs).

asaph 8y ago

How does this defend against a the type of hardware-based attack discussed in the article?

rjst01 8y ago
The same way secure-boot provides protection against hardware modification / evil maid type attacks in CPUs today: by verifying the integrity of the code that's about to be booted before the CPU boots it. It would significantly raise the cost and difficulty of this sort of attack.
- wolfgke 8y ago
  > It would significantly raise the cost and difficulty of this sort of attack. In my opinion, modifying the board layout with the additional chip and modifying the production process for the server boards stealthily already has a pretty high cost and difficulty.
  - rjst01 8y ago
    > already has a pretty high cost and difficulty That's true, but properly implemented secure boot could serve to increase it by an order of magnitude.
monocasa 8y ago
The best guess I've heard is that this attack pulls down the BMC's SPI flash lines in order to corrupt its code as it's loaded. A proper chain of trust that starts on the BMC chip could absolutely protect against that. At that point any modification to the boot image would leave the BMC refusing to boot rather giving attacker control.

subudeepak 8y ago

Hardware attacks cannot be prevented by secure boot...

wolfgke 8y ago
> Hardware attacks cannot be prevented by secure boot... But by Trusted Computing (at least in some implementations).
moonbug 8y ago
The most plausible hypothesis of how this attack works is by corrupting firmware loaded at power-on time over SPI. Secure boot would absolutely protect from that by rejecting the signature of the modified code. By hey, I get that Newsy groupthink means secure boot bad.
- subudeepak 8y ago
  Secure boot is in no way bad :-) Ofcourse, it must in fact be the first point on any sane security checklist. And one of the most common attacks aka. malicious firmware is prevented by using secure boot. Many other classes of attacks like forcing the microcontroller to delete all its data, opening up the debug JTAG port of the microcontroller, preventing the log of certain security events etc. can be achieved with the right settings. Though these are just remote possibilities with high levels of complexity, so is changing a production design of a board.
- asdf2341234 8y ago
  >is by corrupting firmware loaded at power-on time over SPI. >Secure boot would absolutely protect from that by rejecting the signature of the modified code. Why couldn't you also change out the keys so the signature does match?
  - moonbug 8y ago
    Doing so means compromising the TPM on the BMC module which is much harder to do. It's not something that can be done downstream in the supply chain, as this attack is purported to have been.