Disabling Secure Boot signature validation

[mjg59]

One of the benefits of the Shim approach of bridging trust between the Microsoft key and our own keys is that we can define whatever trust policy we want. Some of the feedback we've received has indicated that people really do want the ability to disable signature validation without having to go through the firmware. The problem is in ensuring that this can't be done either accidentally or via trivial social engineering.

We've come up with one possible solution for this. A tool run at the OS level generates a random password and hashes it. This hash is appended to the desired secure boot state and stored in an EFI variable. On reboot, Shim notices that this variable is set and drops to a menu. The user then selects "Change signature enforcement" and types the same password again. The system is then rebooted and Shim now skips the signature validation.

This approach avoids automated attacks - if malware sets this variable, the user will have no idea which password is required. Any social engineering attack would involve a roughly equivalent number of steps to disabling Secure Boot in the firmware UI, so it's not really any more attractive than just doing that. We're fairly confident that this meets everyone's expectations of security, but also guarantees that people who want to run arbitrary kernels and bootloaders can do so.

Comments

How do they know the password

[smoogespace.blogspot.com]

Where does the user know what the password is since it is a random generated and hashed value. I guess there are some steps I am missing.

[marahmarie]

One of the benefits of the Shim approach of bridging trust between the Microsoft key and our own keys is that we can define whatever trust policy we want.

If you can define any trust policy you want, then so can anyone, including your local (or remote, be it as it may) malware author. Explain how the Shim approach benefits the end user if this is the case?

[simont]

Is this not the sort of policy liable to cause whatever upstream authority is signing Shim itself to decide it isn't the sort of thing they're comfortable certifying as safe?

(Or is it simply a laughable idea that a signature on a bootloader certifies anything other than that somebody with halfway plausible credentials gave a lot of money to the signing authority?)

[(Anonymous)]

If users want to run their own kernels then just ask users to disable secure boot in the firmware, because this approach to disabling signature validation will just complicate things.

And why do we need to "trust" Microsoft in order to compete with them. That's like Apple having to "trust" Microsoft just to create the iPhone 6.

[(Anonymous)]

Can I still disable signature validation by disabling secure boot?

Apple keyboards?

[(Anonymous)]

http://arstechnica.com/apple/2009/08/exploit-allows-for-keyboard-ownage-through-firmware/ could be used to automate an attack against Shim. It is not difficult to fix at minor inconvenience to the user.

Approach eases social engineering attacks

[(Anonymous)]

Any social engineering attack would involve a roughly equivalent number of steps to disabling Secure Boot in the firmware UI, so it's not really any more attractive than just doing that.

I thought firmware UIs are so diverse that it is unreasonable/impossible to guide users to the secure boot options. Luckily, this makes it very hard to attack masses of users with single social engineering attacks.

Now the Shim provides a uniform mechanism that can be exploited by a single social engineering attack? ("There is a problem with the signature validation process of your computer. To fix this problem, please reboot and enter 09sifd5b when asked for a password." CLICK-HERE-TO-REBOOT)

Am I something wrong? For me it looks like you're increasing the attractiveness for these kinds of attacks a lot.

[(Anonymous)]

Any status of Secure boot lately after Windows 8 got released?