Garrett: Why UEFI secure boot is difficult for Linux [LWN.net]

Garrett: Why UEFI secure boot is difficult for Linux

Posted Jan 18, 2012 17:13 UTC (Wed) by drag (subscriber, #31333)
In reply to: Garrett: Why UEFI secure boot is difficult for Linux by Mellobob
Parent article: Garrett: Why UEFI secure boot is difficult for Linux

Because the only way to validate the software installed on a computer is by starting at the boot or having a completely separate OS/Machine for validating your software.

Imagine a attacker is able to violate the security of your system. They install what is known as a 'Kernel Level Root Kit'. This software modifies how your kernel behaves in order to hide the fact that your system has been compromised.

This makes any sort of 'root kit scanner' or 'virus scanner' completely worthless. They depend on the kernel syscalls, proc, and such things to provide a accurate picture of what is going on in your machine. Since your system's kernel is now, effectively, the malware your fighting against it is impossible to know if your machine is secure or not.

Previous to 'trusted computing' or 'secure boot' initiatives the only way to validate your installation would be to boot up in a live cdrom or seperate machine or something like that so you could build a checksum of files on your system and compare against a known good list. Needless to say that this is very error prone, difficult, and expensive process.

Any suggestions about running 'rootkitkiller' scripts or trying to use rpm's checksum database to validate your system is just utterly naive at best and downright deceptive and self-defeating generally. Just really useless.

Kernel level root kits have been around in Linux/Unix-land for decades. Now that most Window users are sophisticated enough to run anti-malware and anti-virus in a sophisticated manner they are VERY common. I, personally, have seen several Windows machines with kernel level root kits.

With secure boot loader + signed kernel + signed drivers then theoretically all you have to do to guard against this is to reboot.

Providing your software is not vulnerable to a attack during boot-up it should provide a very effective way to know for certain what is running on your system.

This is currently not possible on Linux unless you go through extraordinary steps.

(Log in to post comments)

Garrett: Why UEFI secure boot is difficult for Linux

Posted Jan 18, 2012 20:31 UTC (Wed) by drag (subscriber, #31333) [Link]

>As long as you have a security hole in the system, which allows anybody to get superuser rights, it matters very little if you are able to secure the boot process or not. If you do, any malware can still gain root privileges just after bootup and hide itself from all security scans.

Sorta.

IF the hole allows the attacking software to subvert the kernel very close to boot up (say before your anti-virus starts) then a secure boot is not going to help you.

This potential for 'runtime hole' is the significant flaw to the system.

But it still provides you a advantage over the malware in that you can do things like update your kernel to a newer version and still be able to trust it. So if you find out that you have a security hole in your kernel and manage to patch it then you get a good chance of defeating the malware. Especially if your kernel has some anti-malware features built into it.

> A real remedy to most common security problems would be locking down applications, not the kernel.

Yes, ideally, you will want to only run perfectly secure applications with perfectly secure configurations and be a perfectly competent administrator.. but we know that is not going to be possible.

So this means that you still have a problem of detecting compromised systems when they occur. Right now Linux does not a effective solution. Having a 'secure chain of trust' at boot up is not a total solution in itself, but I think it's a necessary component.

Garrett: Why UEFI secure boot is difficult for Linux

Posted Jan 18, 2012 23:04 UTC (Wed) by marm (guest, #53705) [Link]

When I want to detect a compromised system, I can easily boot a different system from a safe media. This is easy and much more reliable than relying on secure boot features.

> Yes, ideally, you will want to only run perfectly secure applications with perfectly secure configurations and be a perfectly competent administrator.. but we know that is not going to be possible.

Still, even insecure applications can be sandboxed by the system, so that the harm they can incur is very limited.

As long as remote malware is easily able to delete all my files or upload them on RapidShare due to buggy applications, I do not really care if the rest of the OS is compromised.

This is not really true, of course...

Posted Jan 18, 2012 20:38 UTC (Wed) by khim (subscriber, #9252) [Link]

As long as you have a security hole in the system, which allows anybody to get superuser rights, it matters very little if you are able to secure the boot process or not.

You assume hole can not be patched - why?

If you do, any malware can still gain root privileges just after bootup and hide itself from all security scans.

Not really. It's easy to create secure update process which just checks the signature and then applies update to your OS. Since it'll do just an update and will include tiny amount of code it can be made pretty bullet-proof.

This is not theory - it was checked on practice. PS3 had extensive multiplayer protection, but eventually (after many years) it was broken. And for a relatively brief time (half-year or so) you had the ability to crack PS3 open using hardware token. Almost everything was compromised: hypervisor, loader, etc. Just one thing survived: secure boot and update system. Now, year after release of 3.56 firmware various cracker sites still contain the same messages in large red letters: For those on v3.56 or v3.60 or v3.61 or v3.66 or v.400- NO Downgrade, NO Jailbreak and NO CFW!.

Sure, the fact that SONY used secure boot to protect PS3 from it's owner is despicable, but the story proves capabilities of secure boot quite nicely.