![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59One 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.
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.
Approach eases social engineering attacks
Date: 2012-10-19 02:58 pm (UTC)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.
Re: Approach eases social engineering attacks
Date: 2012-10-19 03:49 pm (UTC)Re: Approach eases social engineering attacks
Date: 2012-10-19 03:49 pm (UTC)Re: Approach eases social engineering attacks
Date: 2012-10-20 01:09 pm (UTC)While I'm impressed by Matthew's work, I never understood this (fundamental!) argument of his.
1. There are NOT that many BIOS vendors and there are NOT that many different BIOS interfaces.
2. People need to mess with their BIOS ANYWAY to boot from a CD or USB stick!
PS: I know and like and use GRUB4DOS but it's much less newbie friendly than all the above.
Re: Approach eases social engineering attacks
Date: 2012-10-20 03:48 pm (UTC)It's different for pretty much every laptop vendor, and often within different ranges from the same vendor.
"People need to mess with their BIOS ANYWAY to boot from a CD or USB stick!"
This is typically untrue (there's a separate interface for choosing a one-off boot device), and entirely untrue with UEFI.
Re: Approach eases social engineering attacks
Date: 2012-10-21 09:41 pm (UTC)Not my experience. Maybe I don't see the subtle differences any more. Or I've just been lucky.
"there's a separate interface for choosing a one-off boot device"
Only on not too old PCs but you're right it really makes things easier. It's still not the pinnacle of user friendliness though.
"..., and entirely untrue with UEFI."
Sorry if I missed one of your previous blog but... what are you referring to here? I've installed Linux on a number of (non-secure) EFI laptops already and it was not any different from any pre-EFI laptop. What did I miss?
(In fact, for most of these laptops it was actually hard to notice they were using EFI at all)
Re: Approach eases social engineering attacks
Date: 2012-10-23 02:02 am (UTC)Re: Approach eases social engineering attacks
Date: 2012-10-23 11:29 pm (UTC)Re: Approach eases social engineering attacks
Date: 2012-10-23 11:42 pm (UTC)Re: Approach eases social engineering attacks
Date: 2012-10-24 05:31 pm (UTC)Re: Approach eases social engineering attacks
Date: 2012-10-24 05:36 pm (UTC)Re: Approach eases social engineering attacks
Date: 2012-10-24 06:21 pm (UTC)