User: Password:
|
|
Subscribe / Log in / New account

No signed kernel, just a signed boot loader

No signed kernel, just a signed boot loader

Posted Jun 25, 2012 4:10 UTC (Mon) by mjg59 (subscriber, #23239)
In reply to: No signed kernel, just a signed boot loader by hummassa
Parent article: Details on Ubuntu's UEFI secure boot plan

The idea of secure boot is to ensure that it's as difficult as possible to run untrusted code before you've set up your desired trust chain. If you can launch untrusted code within the Linux kernel then it's a simple matter to use that as an attack vector for Windows - rather than writing your malware from scratch, you drop a copy of the exploitable kernel in the EFI system partition, provide a trivial initramfs that gets you into the kernel, pass in the NT kernel and appropriate drivers, set up the loader parameter block, set up some new page tables and jump into the Windows kernel. Of course, rather than just booting it you've taken the opportunity to compromise it in some subtle way. Windows boots slightly more slowly than usual, but there's no reason for most users to notice - and worse, the malware checking code that would normally be able to rely on the kernel not having to be compromised is now unable to do anything useful.

So that's the why - breaking the trust barrier results in revocation. The how is a little more difficult. There's two ways you can revoke binaries. The first is to add an update of the specific SHA256. That makes sense in many cases, but probably isn't the best choice here - any older kernels are presumably also compromisable. So instead you just revoke the individual signing key and sign your kernels with a new one. How will that scale? Great question. We'll find out.

And yes obviously there's the risk of implementation flaws. The cryptographic model in use is believed to be sound, and we assume that Microsoft have learned from their mistakes with the Terminal Server key. Is that a guarantee? No. But then SSL isn't guaranteed to be safe either, and people still rely on that. Proving security is hard.


(Log in to post comments)

No signed kernel, just a signed boot loader

Posted Jun 25, 2012 12:28 UTC (Mon) by hummassa (subscriber, #307) [Link]

There are a lot of problems in this.

> The idea of secure boot is to ensure that it's as difficult as possible to run untrusted code before you've set up your desired trust chain. If you can launch untrusted code within the Linux kernel then it's a simple matter to use that as an attack vector for Windows - rather than writing your malware from scratch, you drop a copy of the exploitable kernel in the EFI system partition, provide a trivial initramfs that gets you into the kernel, pass in the NT kernel and appropriate drivers, set up the loader parameter block, set up some new page tables and jump into the Windows kernel. Of course, rather than just booting it you've taken the opportunity to compromise it in some subtle way. Windows boots slightly more slowly than usual, but there's no reason for most users to notice - and worse, the malware checking code that would normally be able to rely on the kernel not having to be compromised is now unable to do anything useful.

> So that's the why - breaking the trust barrier results in revocation.

That is the first problem with secure boot: KNOWINGLY breaking the trust barrier results in revocation. Worse yet: breaking the trust barrier knowingly and from the point of view of anyone in the trust chain results in revokation. This is preposterous, because it causes revocation against the will of the computer owner. So, I have to agree with jiu and eduperez and say that "secure boot was devised to distract the energy of people building linux to hinder their progress" and "Secure boot was created to lock users out of their own computers".

Those two problems amount to: if someone in a high position in the "trust chain" can lock you out of your own computer because "fsck you, that's why", they can. More: they cannot lock malware out of your computer because (1) it is difficult/impossible to know what is malware after all and (2) lots of malware will stay hidden and the vulnerabilities that lead to infection and pnwing will not generate key revocations because people in the trust chain do not know about them. Again, stuxnet and flame are good example of "hidden for about two years", which is plenty of time for doing plenty of sabotage and espionage.

And then the problems in the how:

> The how is a little more difficult. There's two ways you can revoke binaries. The first is to add an update of the specific SHA256. That makes sense in many cases, but probably isn't the best choice here - any older kernels are presumably also compromisable. So instead you just revoke the individual signing key and sign your kernels with a new one. How will that scale? Great question. We'll find out.

It does not scale at all.

I have stated above that the why is a flawed premise. But the how is a nightmare. For someone to revoke a key what you have to do is to write that key or that sha256 or whatever to a database that will be read in the UEFI level. THAT, per se, is a huge vulnerability. Who writes that database? How is that database read (and checked for veracity) by the UEFI level? When? At boot time via the network (spoofable)? Read from disk (corruptible)? Signed? With the same key you are revoking? With an escrow key that can be used to revoke any key? You load a new key how? If all keys are revoked, what happens?

Basically, in security terms, you are revoking access to the computer for someone based on an externally-entered (coming from the network, no less!) string. This is as tainted as it gets.

But it only gets worse: the platforms (Linux/Windows8) and their kernels are not security proven and are not even security-oriented. They present lots of opportunities for attacks and they will continue doing so for a long time. It is virtually impossible to plug every single hole in them and it's impossible to revoke the key that signs them at every single vulnerability because if you do that (1) your revoked keys database will be huge and (2) you will force updates down the throats of the users, effectively locking them out of their computers, not forgetting (3) opening up new opportunities to attacks coming from the infrastructure outside the trust chain.

> And yes obviously there's the risk of implementation flaws. The cryptographic model in use is believed to be sound, and we assume that Microsoft have learned from their mistakes with the Terminal Server key. Is that a guarantee? No. But then SSL isn't guaranteed to be safe either, and people still rely on that. Proving security is hard.

The problem is, I am not even factoring implementation flaws, above. Just normal vulnerabilities (buffer overflows, integer overflows, finite state unexpected transitions, etc) and normal attacks OUTSIDE the "chain of trust" implementations (key distribution for reloading and revoking, etc).

And we still have to factor in cryptographic security failures that are sometimes exploitable (hash/signature collisions were used in Flame IIRC)...

No signed kernel, just a signed boot loader

Posted Jun 25, 2012 13:43 UTC (Mon) by mjg59 (subscriber, #23239) [Link]

If only the revocation mechanisms were documented in some kind of specification, or something. Wouldn't that be wonderful?

No signed kernel, just a signed boot loader

Posted Jun 25, 2012 13:48 UTC (Mon) by hummassa (subscriber, #307) [Link]

linky linky?

No signed kernel, just a signed boot loader

Posted Jun 25, 2012 13:51 UTC (Mon) by mjg59 (subscriber, #23239) [Link]

No signed kernel, just a signed boot loader

Posted Jun 26, 2012 1:49 UTC (Tue) by hummassa (subscriber, #307) [Link]

I had got it just before I saw your link; thanks. I will read it carefully in the next day or so (if $DAYJOB and $HOMECARE give me some space) and will get back to you. But I will tell you beforehand that if the mechanisms are not crowded with possible attack vectors I will be VERY pleasantly surprised.

No signed kernel, just a signed boot loader

Posted Jun 25, 2012 15:49 UTC (Mon) by raven667 (subscriber, #5198) [Link]

> This is preposterous, because it causes revocation against the will of the computer owner. So, I have to agree with jiu and eduperez and say that "secure boot was devised to distract the energy of people building linux to hinder their progress" and "Secure boot was created to lock users out of their own computers".

This is BS because the owner can create their own keys, disable secure boot, etc. so they can't be shut out of their machine against their will, that is not a real thing. Now if you start talking about boot locked machines that might be a different story but we definitely are not talking about that, even MS wants to make sure x86 hosts aren't boot locked (only their ARM tablets, like many Android devices).

In any event this is a feature that can be used for the good of the system by the system owner and that is what Linux will use it for.

No signed kernel, just a signed boot loader

Posted Jun 26, 2012 18:10 UTC (Tue) by rahvin (subscriber, #16953) [Link]

The only reason MS changed (yes changed) the spec to allow disabling secure boot was because of public outcry. As others have pointed out this was one of the bullet points in the halloween memo (leveraging hardware alliances to lock out linux). It would be foolish to dismiss this potential motivation as MS sees Android as a significant threat.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds