5 ms·

OP/bug finder here with some clarifying information. It's a common misconception that this issue can only be abused if you use HTTP boot. That is not the case a

OP/bug finder here with some clarifying information. It's a common misconception that this issue can only be abused if you use HTTP boot. That is not the case at all, otherwise it wouldn't be Critical. This bug can be abused locally (privileged malware can overwrite the EFI partition), from an adjacent network if PXE boot is enabled (w/ MiTM), or remotely if HTTP boot is used (w/ MiTM). More details on these scenarios: 1. A remote attacker with no privileges in a man-in-the-middle (MitM) position could leverage the issue against a victim machine that uses HTTP boot. No direct access to the victim machine is required. 2. A remote attacker with privileges and code execution on the victim machine could leverage the issue to bypass Secure Boot, even if the victim does not already use HTTP boot (as long as firmware has HTTP support). How? Several ways: - An attacker can edit the boot order variable to specify a controlled attacker server. - An attacker can chain shim->GRUB2->shim (via HTTP). For this technique, an attacker would overwrite the boot loader in the EFI partition to a legitimate shim and GRUB2 image. The attacker would create a grub.cfg that chainloads a new shim via HTTP. This is possible because GRUB2's device syntax allows you to specify any supported device, including HTTP (if available). 3. An adjacent attacker with no privileges in a man-in-the-middle (MitM) position could leverage the issue against a victim machine that uses PXE boot. PXE is separate from HTTP boot, but similar to the local vector, an attacker can chain together shim (via PXE)->GRUB2 (via PXE)->shim (via HTTP).

Arnavion 3y ago
Yes, if the attacker can edit the the victim machine's EFI vars or the contents of its ESP, then they can make the victim machine use HTTP boot even if the victim machine didn't use HTTP boot originally. However at that point they can also wreak more havoc without involving HTTP boot. For the case where the default configuration has been set up to just chainload grub (ie what distros use shim for), and where an attacker editing EFI vars / ESP is not in the threat model, there is no concern. Yes that is just "It's not a concern because you defined it to not be." but that is the reality for most users of Secure Boot on Linux. Also note that the reason I wrote that paragraph is because the HN submission was originally submitted with a title along the lines of "Every install of shim is affected".
- lmm 3y ago
  > Yes, if the attacker can edit the the victim machine's EFI vars or the contents of its ESP, then they can make the victim machine use HTTP boot even if the victim machine didn't use HTTP boot originally. However at that point they can also wreak more havoc without involving HTTP boot. How? The whole point of secure boot is that an attacker with even that level of access can't boot the machine in an authenticated way (and e.g. make the disk encryption key available).
  - Arnavion 3y ago
    >How? Someone with enough privileged access to write to the ESP (ie root) can also add their own MOK to the ESP that the user might blindly accept next time they boot. Especially if they time it for when there is a legitimate new MOK in the ESP waiting to be accepted on next boot, so that the user is predisposed to accepting a new key. They can also replace shim with other binaries with other vulnerabilities that were signed by the MS key in the past, in case DBX hasn't been updated with their hashes. >The whole point of secure boot is that an attacker with even that level of access can't boot the machine in an authenticated way (and e.g. make the disk encryption key available). Someone with enough privileged access to write to the ESP (ie root) can also just exfiltrate your disk contents at that point.
    - lmm 3y ago
      > Someone with enough privileged access to write to the ESP (ie root) can also add their own MOK to the ESP that the user might blindly accept next time they boot. Especially if they time it for when there is a legitimate new MOK in the ESP waiting to be accepted on next boot, so that the user is predisposed to accepting a new key. > They can also replace shim with other binaries with other vulnerabilities that were signed by the MS key in the past, in case DBX hasn't been updated with their hashes. Neither of those sounds like a sure thing. The first relies on the user not checking the key, and is exposing the attacker to a lot of risk if they do. The second relies on DBX not being updated, for which the remedy is "don't do that". > Someone with enough privileged access to write to the ESP (ie root) can also just exfiltrate your disk contents at that point. The idea is that your main data partition is encrypted with a key held in a secure enclave and can only be retrieved after a secure boot. (Or, y'know, any of the other things people would use secure boot for). Your boot partition has to be unencrypted so you can boot from it, but there's no sensitive data on there, and an attacker with write access can't "rootkit" it because if they replace the bootloader with a different one then it will be unsigned and break the chain of trust. Again if this stuff didn't work then there would be no point in secure boot at all.

Arnavion 3y ago

Yes, if the attacker can edit the the victim machine's EFI vars or the contents of its ESP, then they can make the victim machine use HTTP boot even if the victim machine didn't use HTTP boot originally. However at that point they can also wreak more havoc without involving HTTP boot. For the case where the default configuration has been set up to just chainload grub (ie what distros use shim for), and where an attacker editing EFI vars / ESP is not in the threat model, there is no concern. Yes that is just "It's not a concern because you defined it to not be." but that is the reality for most users of Secure Boot on Linux. Also note that the reason I wrote that paragraph is because the HN submission was originally submitted with a title along the lines of "Every install of shim is affected".

lmm 3y ago
> Yes, if the attacker can edit the the victim machine's EFI vars or the contents of its ESP, then they can make the victim machine use HTTP boot even if the victim machine didn't use HTTP boot originally. However at that point they can also wreak more havoc without involving HTTP boot. How? The whole point of secure boot is that an attacker with even that level of access can't boot the machine in an authenticated way (and e.g. make the disk encryption key available).
- Arnavion 3y ago
  >How? Someone with enough privileged access to write to the ESP (ie root) can also add their own MOK to the ESP that the user might blindly accept next time they boot. Especially if they time it for when there is a legitimate new MOK in the ESP waiting to be accepted on next boot, so that the user is predisposed to accepting a new key. They can also replace shim with other binaries with other vulnerabilities that were signed by the MS key in the past, in case DBX hasn't been updated with their hashes. >The whole point of secure boot is that an attacker with even that level of access can't boot the machine in an authenticated way (and e.g. make the disk encryption key available). Someone with enough privileged access to write to the ESP (ie root) can also just exfiltrate your disk contents at that point.
  - lmm 3y ago
    > Someone with enough privileged access to write to the ESP (ie root) can also add their own MOK to the ESP that the user might blindly accept next time they boot. Especially if they time it for when there is a legitimate new MOK in the ESP waiting to be accepted on next boot, so that the user is predisposed to accepting a new key. > They can also replace shim with other binaries with other vulnerabilities that were signed by the MS key in the past, in case DBX hasn't been updated with their hashes. Neither of those sounds like a sure thing. The first relies on the user not checking the key, and is exposing the attacker to a lot of risk if they do. The second relies on DBX not being updated, for which the remedy is "don't do that". > Someone with enough privileged access to write to the ESP (ie root) can also just exfiltrate your disk contents at that point. The idea is that your main data partition is encrypted with a key held in a secure enclave and can only be retrieved after a secure boot. (Or, y'know, any of the other things people would use secure boot for). Your boot partition has to be unencrypted so you can boot from it, but there's no sensitive data on there, and an attacker with write access can't "rootkit" it because if they replace the bootloader with a different one then it will be unsigned and break the chain of trust. Again if this stuff didn't work then there would be no point in secure boot at all.