[lmm]

> 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]

>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]

> 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]

>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]

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.

[michaelt]

Depends.

You can set up 'measured boot' so the TPM will only 'unseal' the disk encryption password if you're running a certain version of your BIOS, a certain set of Machine Owner Keys, a certain version of shim, a certain kernel, a certain kernel command line and so on.

Very few normal users do this because it's a great deal of effort/risk for very modest security improvements. But the option is present - it's sometimes used by big corporations making TiVo-style products to lock out the owners from messing with the hard disk in the manner you've described.

[lmm]

> Not updating DBX is the default state. Updating it is what requires effort.

Up to a point, but that's true for almost everything in software. Not updating your OS etc. is the default state, and if it's not up to date it will be full of holes. That's life.

> 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.

If they have root on the live system then they don't need to mess around attacking secure boot at all. The point is "evil maid" style attacks where someone messes with the boot partition (and/or firmware) by booting off another device. Again, this is the whole point of Secure Boot; if you don't care about that kind of scenario then why would you ever be using secure boot at all?

[Arnavion]

>The point is "evil maid" style attacks where someone messes with the boot partition (and/or firmware) by booting off another device.

This subthread is descended from https://news.ycombinator.com/item?id=39135275 which talks about "remote attackers". Nobody's talking about evil maid attacks.