3 ms·

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 vict

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
      >The second relies on DBX not being updated, for which the remedy is "don't do that". Not updating DBX is the default state. Updating it is what requires effort. How many devices actually have up-to-date DBX? I know I mentioned LVFS in my first comment, but I have to wonder how many Linux devices with SB enabled actually use it. The ones that don't will not have updated their DBX since they were manufactured. >The idea is that your main data partition is encrypted with a key held in a secure enclave [...] You're missing the point. An attacker that can write to the ESP is root on the live system right now. It can exfiltrate the contents of `/` right now. Or if it can't exfiltrate right now, it can install an OS service to do that on future boots.
      - lilyball 3y ago
        If the boot partition isn't encrypted, doesn't this mean an attacker with physical access to the machine can remove the drive, plug it into their own machine, overwrite the boot partition, then restore the drive back in the original machine? In that scenario they don't have access to the unencrypted root filesystem.

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
    >The second relies on DBX not being updated, for which the remedy is "don't do that". Not updating DBX is the default state. Updating it is what requires effort. How many devices actually have up-to-date DBX? I know I mentioned LVFS in my first comment, but I have to wonder how many Linux devices with SB enabled actually use it. The ones that don't will not have updated their DBX since they were manufactured. >The idea is that your main data partition is encrypted with a key held in a secure enclave [...] You're missing the point. An attacker that can write to the ESP is root on the live system right now. It can exfiltrate the contents of `/` right now. Or if it can't exfiltrate right now, it can install an OS service to do that on future boots.
    - lilyball 3y ago
      If the boot partition isn't encrypted, doesn't this mean an attacker with physical access to the machine can remove the drive, plug it into their own machine, overwrite the boot partition, then restore the drive back in the original machine? In that scenario they don't have access to the unencrypted root filesystem.