Matthew Garrett ([personal profile] mjg59) wrote,
@ 2012-10-17 06:02 pm UTC
Entry tags:advogato, fedora
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.

(33 comments) - (Post a new comment)
(Flat) (Top-level comments only)

How do they know the password


[identity profile] smoogespace.blogspot.com
2012-10-17 10:27 pm UTC (link)
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.

(Reply to this)  (Thread) 


Re: How do they know the password


[personal profile] mjg59
2012-10-17 10:37 pm UTC (link)
It's printed when they run the command.

(Reply to this)  (Thread from start)  (Parent) 


Re: How do they know the password


(Anonymous)
2012-10-17 10:37 pm UTC (link)
"To disable Secure Boot signature validation, please type the following string when prompted to at boot time: fKrl0pt15KCS"

(Reply to this)  (Thread from start)  (Parent)  (Thread) 


Re: How do they know the password


[identity profile] smoogespace.blogspot.com
2012-10-17 10:53 pm UTC (link)
Thanks. That wasn't clear how this was shown to the user.

(Reply to this)  (Thread from start)  (Parent) 


Re: How do they know the password


[identity profile] ff426444-2eac-4286-8f78-f088e98a036e [openid.stackexchange.com]
2012-10-18 01:27 am UTC (link)
Why wouldn't malware impersonate this user-space tool, generate a hash of its design, and print something like "At next reboot, type YES to continue."

(Reply to this)  (Thread from start)  (Parent)  (Thread) 


marahmarie: Sheep go to heaven, goats go to hell (sheep)

Re: How do they know the password


[personal profile] marahmarie
2012-10-18 01:49 am UTC (link)
Always my first thought and why I have trouble taking this topic seriously. Until you can iron out every wrinkle here, what is the point.

(Reply to this)  (Thread from start)  (Parent) 


Re: How do they know the password


[personal profile] mjg59
2012-10-18 01:54 am UTC (link)
On reboot you'll be faced with a prompt saying "Continue" and a countdown. If you select "Continue" or wait for the timer to expire, your system will boot. You'll need to select "Disable Secure Boot" and then type the password.

Could malware convince users to do that? Yes. Could malware convince users to just do the same through their firmware menus? Yes. If the option exists (as Microsoft require it to on x86) there will always be some people who can be convinced to change it without knowing what they're doing. There's no way of keeping those people safe.

(Reply to this)  (Thread from start)  (Parent)  (Thread) 


Re: How do they know the password


(Anonymous)
2012-10-18 12:00 pm UTC (link)
Enforcing a minimum password length (or even a complexity, e.g. requiring a digit) within a shim would make this kind of attacks more difficult.

At the very least, a zero-length password should definitely be prohibited.

(Reply to this)  (Thread from start)  (Parent)  (Thread) 


Re: How do they know the password


[personal profile] mjg59
2012-10-18 04:06 pm UTC (link)
Yeah, right now the password has to be 8 characters. We could definitely enforce some additional constraints there.

(Reply to this)  (Thread from start)  (Parent)  (Thread) 


Re: How do they know the password


(Anonymous)
2012-10-18 05:32 pm UTC (link)
One way to enforce ugliness of passwords would be to require that the password be a hash of some information provided to the firmware by the userland program, so the userland program can only choose a password if it can reverse the hash. OTOH, that might require rather long passwords and does rather conflict with sending the password to the firmware as a hash.

(Reply to this)  (Thread from start)  (Parent) 


marahmarie: Sheep go to heaven, goats go to hell (sheep)


[personal profile] marahmarie
2012-10-18 01:52 am UTC (link)
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?

(Reply to this)  (Thread) 



[personal profile] mjg59
2012-10-18 01:56 am UTC (link)
Secure boot isn't intended to protect against physically present attack. If your malware author is local, your malware author has potentially also just inserted a hardware keylogger into your system. Any modification of local policy requires the physically present end user to interact with the system, so while it's possible to socially engineer a naive end user into disabling security, it's almost certainly more work than just asking them for their credit card number straight off.

(Reply to this)  (Thread from start)  (Parent) 


simont: (shorthair)


[personal profile] simont
2012-10-18 08:24 am UTC (link)
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?)

(Reply to this)  (Thread) 



[personal profile] mjg59
2012-10-18 04:05 pm UTC (link)
The model is that Microsoft will sign pretty much anything (within reason) but will revoke signatures if (and only if) the binary is actually used to attack systems. It's up to the vendor of the bootloader what kind of security policy they want to construct and what risks they're willing to take in order to ensure that their bootloader isn't used that way.

(Reply to this)  (Thread from start)  (Parent) 


Anonymity


(Anonymous)
2012-10-20 11:01 am UTC (link)
One thing malware authors badly need and work really hard to achieve is anonymity.

"Hi Microsoft! Sell me a Secure Boot certificate but please also make sure you will never be able to find me again."

Impossible? No. Very difficult? Yes, likely to be. Less malware (in numbers) is more security.

(Reply to this)  (Thread from start)  (Parent) 



(Anonymous)
2012-10-18 03:21 pm UTC (link)
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.

(Reply to this) 



(Anonymous)
2012-10-18 06:02 pm UTC (link)
Can I still disable signature validation by disabling secure boot?

(Reply to this)  (Thread) 



[personal profile] mjg59
2012-10-18 06:09 pm UTC (link)
Yes.

(Reply to this)  (Thread from start)  (Parent) 


Apple keyboards?


(Anonymous)
2012-10-19 03:25 am UTC (link)
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.

(Reply to this)  (Thread) 


Re: Apple keyboards?


[personal profile] mjg59
2012-10-19 03:44 am UTC (link)
If you can upload arbitrary firmware to the keyboard then you can just steal passwords that way.

(Reply to this)  (Thread from start)  (Parent) 


Approach eases social engineering attacks


(Anonymous)
2012-10-19 02:58 pm UTC (link)
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.

(Reply to this)  (Thread) 


Re: Approach eases social engineering attacks


(Anonymous)
2012-10-19 03:49 pm UTC (link)
I think he is. The shim should just boot into grub, and have a configuration file to see if the user wants to enable secure boot signature signing ot not

(Reply to this)  (Thread from start)  (Parent)  (Thread) 


Re: Approach eases social engineering attacks


(Anonymous)
2012-10-19 03:49 pm UTC (link)
I meant or not ot

(Reply to this)  (Thread from start)  (Parent) 


Re: Approach eases social engineering attacks


(Anonymous)
2012-10-20 01:09 pm UTC (link)
"I thought firmware UIs are so diverse that it is unreasonable/impossible to guide users to the secure boot options."

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.

(Reply to this)  (Thread from start)  (Parent)  (Thread) 


Re: Approach eases social engineering attacks


[personal profile] mjg59
2012-10-20 03:48 pm UTC (link)
"There are NOT that many BIOS vendors and there are NOT that many different BIOS interfaces."

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.

(Reply to this)  (Thread from start)  (Parent)  (Thread) 


Re: Approach eases social engineering attacks


(Anonymous)
2012-10-21 09:41 pm UTC (link)
"It's different for pretty much every laptop vendor, and often within different ranges from the same vendor."

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)

(Reply to this)  (Thread from start)  (Parent)  (Thread) 


Re: Approach eases social engineering attacks


[personal profile] mjg59
2012-10-23 02:02 am UTC (link)
I should have been clearer there. There's a huge change with Windows 8 platforms - most machines won't initialise the keyboard before boot, they'll leave that up to the OS. So you can't get into any kind of firmware boot menu at powerup time - if you boot Windows 8, in order to boot off removable media, you hold down shift while clicking poweroff and the system reboots into the bootloader, and there's a GUI for selecting the removable media you want to boot off.

(Reply to this)  (Thread from start)  (Parent)  (Thread) 


Re: Approach eases social engineering attacks


(Anonymous)
2012-10-23 11:29 pm UTC (link)
Why do Windows 8 PCs not initialize the keyboard before boot? How would anyone go into the firmware to disable secure boot or set the system clock?

(Reply to this)  (Thread from start)  (Parent)  (Thread) 


Re: Approach eases social engineering attacks


[personal profile] mjg59
2012-10-23 11:42 pm UTC (link)
To speed boot time. The bootloader can set a flag, and on next reboot the system will enter the firmware menu.

(Reply to this)  (Thread from start)  (Parent)  (Thread) 


Re: Approach eases social engineering attacks


(Anonymous)
2012-10-24 05:31 pm UTC (link)
How would I enter the firmware menu from Linux?

(Reply to this)  (Thread from start)  (Parent)  (Thread) 


Re: Approach eases social engineering attacks


[personal profile] mjg59
2012-10-24 05:36 pm UTC (link)
Set that flag in the appropriate variable, reboot.

(Reply to this)  (Thread from start)  (Parent)  (Thread) 


Re: Approach eases social engineering attacks


(Anonymous)
2012-10-24 06:21 pm UTC (link)
How would I set that flag?

(Reply to this)  (Thread from start)  (Parent) 



(Anonymous)
2012-10-28 10:37 pm UTC (link)
Any status of Secure boot lately after Windows 8 got released?

(Reply to this) 


(33 comments) - (Post a new comment)
(Flat) (Top-level comments only)