| |||||||||||||
Garrett: Why UEFI secure boot is difficult for LinuxGarrett: Why UEFI secure boot is difficult for LinuxPosted Jan 18, 2012 17:00 UTC (Wed) by Mellobob (guest, #82390)Parent article: Garrett: Why UEFI secure boot is difficult for Linux
I'm not an expert in security. At all. But, why is so much being done at the boot end of this? After all, most people effected by computer in-security are windows users who probably never do anything at a boot level. Get get zapped by malware and viruses which are installed much later than boot.
I may be wrong (again) but I suspect that this has nothing to do with security ... except the security of forcing people to commit to a certain OS.
(Log in to post comments)
Garrett: Why UEFI secure boot is difficult for Linux Posted Jan 18, 2012 17:13 UTC (Wed) by drag (subscriber, #31333) [Link]
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.
Garrett: Why UEFI secure boot is difficult for Linux Posted Jan 18, 2012 19:27 UTC (Wed) by marm (guest, #53705) [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.
A real remedy to most common security problems would be locking down applications, not the kernel.
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.
Garrett: Why UEFI secure boot is difficult for Linux Posted Jan 18, 2012 17:18 UTC (Wed) by Kit (guest, #55925) [Link] It's not about when your computer gets infected, but about how deeply the infection can wiggle itself into your system.I'm not sure how far the signing of 'secure boot' is supposed to go, but it will at least ensure some components you're loading from disk are trustworthy at the time. The virus could still implant itself as the first component of the boot process that isn't signed, but at least that would make it a bit harder, and slightly lower the places it could potentially be hiding (not by a large amount, obviously). It certainly isn't perfect, and it certainly won't make your system magically "secure", but it is a step in the right direction. Of course, just like as said in the comments to the "NSA releases security-enhanced Android" right before this article, it could be used as a weapon against the user as well. Microsoft might be motivated in part by limiting the growth of Linux... although, I honestly doubt that they're really all that worried about Linux on the desktop. Limiting Android is a more reasonable claim, but, even that doesn't seem likely, as manufacturers will likely be releasing variants of the same model running Android. Google should have no issues signing Android, nor should the manufacturers themselves. The question, in this case, would be how hard would it be for CyanogenMod and other independent groups to get their keys added.
Garrett: Why UEFI secure boot is difficult for Linux Posted Jan 18, 2012 17:44 UTC (Wed) by stumbles (guest, #8796) [Link] And that is why I say secure boot is nothing but a sham. Booting is not and has never been the problem, its what happens after and secure boot will do zero for that. This is nothing but the proprietary world trying to AOL-ize themselves against anything not proprietary.
Garrett: Why UEFI secure boot is difficult for Linux Posted Jan 18, 2012 17:54 UTC (Wed) by drag (subscriber, #31333) [Link]
> And that is why I say secure boot is nothing but a sham.
It's very much not a sham. As long as you are the one that controls the keys to your own machine then it can be a fantastic thing.
Anytime you deal with securing your OS it's a trade off between usability and security. Keeping that in mind: While it is a PITA to deal with at installation time it is necessary feature if you want to have the possibility of verifying the functioning of your OS.
Now, naturally, Microsoft is doing it for a verity of reasons that go beyond making sure your system is verifiable, but that does not mean that it cannot be a useful tool for Linux users.
Garrett: Why UEFI secure boot is difficult for Linux Posted Jan 18, 2012 18:53 UTC (Wed) by stumbles (guest, #8796) [Link] It is not a necessary feature I want because it prevents nothing, secures nothing after boot. The probability or rather the reoccurring nature of someone sneaking into a workplace or your home to install a "rogue virus infected" OS is slim to none. But thanks for trying to get me to drink the Kool-Aid.
Garrett: Why UEFI secure boot is difficult for Linux Posted Jan 18, 2012 19:23 UTC (Wed) by drag (subscriber, #31333) [Link]
> It is not a necessary feature I want because it prevents nothing, secures nothing after boot.
If you do not have a secure way to boot your machine then you cannot verify what is running on it after boot unless you are absolutely sure that your machine has never been successfully attacked.
Plain and simple.
Garrett: Why UEFI secure boot is difficult for Linux Posted Jan 18, 2012 23:08 UTC (Wed) by stumbles (guest, #8796) [Link] Secure boot would not fix that anyway. All the little nasty viruses, keyloggers and their ilk can hide anywhere within an OS and if not in the OS, then choose your poison (application). Still not convinced this is anything more than a solution looking for a problem. At the very minimum it will be another attack avenue for the proprietary world.
Garrett: Why UEFI secure boot is difficult for Linux Posted Jan 19, 2012 9:34 UTC (Thu) by mastro (subscriber, #72665) [Link]
Either the bad guys can run code as root on my machine or they don't.
If they don't, then my boot is already 100% secure because they can't change the boot sector of my disk, the bootloader configuration, the initrd, the kernel or the init scripts.
If they DO have root access, it's because they've found some remote exploit (I keep all my distros up-to-date with security updates, but zero-days are still possible) because I for sure didn't give them a legitimate account on my machine, much less physical access to it.
And if they have found a successful remote exploit, everything I do at boot is pointless, they'll still have full control of my machine. And that INCLUDES the possibility of preventing any security update from being successful while still giving to me the appearance of a completely updated and secure system unless I pay *very* close attention.
There's a reason why a compromised system must never be just *fixed*, it must be rebuilt from a clean install.
Look, the root of the problem is: the boot process must not be modifiable without the consent of the device's owner but must also easy to change for the owner if they want to.
The current boot process does achieve both these goals, UEFI "secure" boot doesn't.
Not even close. Posted Jan 19, 2012 9:57 UTC (Thu) by khim (subscriber, #9252) [Link] And that INCLUDES the possibility of preventing any security update from being successful while still giving to me the appearance of a completely updated and secure system unless I pay *very* close attention. Bullshit. Either you are not looking around you don't undestand how it's done. I've already written about it. You need secure boot and secure kernel update mechanism. That's all. Update mechanism can be much, MUCH, MUCH simpler then the full Linux kernel. You just send update with encrypted new random private key and then (when remote system acknoleged update and supposedly installed it) ask to sign a challenge with this new private key. If there are no response or if response is wrong then you know system was hosed and should be disconnected. There's a reason why a compromised system must never be just *fixed*, it must be rebuilt from a clean install. Right. But with secure boot you can keep you "clear install" on the same physical media as the rest of the system :-) Look, the root of the problem is: the boot process must not be modifiable without the consent of the device's owner but must also easy to change for the owner if they want to. Of course it does! You don't own Windows or iOS. You rent it. The real owner is Microsoft, Apple, etc. And UEFI boot absolutely does provide the required capability for the real owner (see above). The real owners were long concerned by the fact that mere lessee can change the system without their consent. UEFI is solution for this problem. After public outcry they decided to allow this capability for some time on x86, but ARM is a new platform and it'll be created properly from the start: real owner will have the ability to rebuild the system while mere tenant will not. What's your problem?
Garrett: Why UEFI secure boot is difficult for Linux Posted Jan 18, 2012 21:30 UTC (Wed) by elanthis (guest, #6227) [Link]
You are missing a serious part of the picture here. SecureBoot by itself just secures the OS kernel. An OS supporting SecureBoot is expected to use the Trusted Computing modules to protect runtime services and Administrator-level processes. The end result is that even if you get a virus somehow that gets into the kernel, you can just reboot into Safe Mode and clean it out safely. Without Secure Boot, you can't trust any of the other security measures to still be effective, so the only recourse after a compromise is to wipe everything and reinstall from scratch on new hardware with clean firmware. Which can range from "annoying" to "prohibitively f**king time consuming and expensive."
All security is just risk management. Nothing makes you 100% safe, but you can take steps to make yourself safer than you were before. By your logic, we might as well remove security levels, passwords, sandboxes, and firewalls, since none of those actually stop a dedicated hacker from getting into your systems. Obviously you don't believe that because you know that they add some value and reduce risks. SecureBoot is just another small step that reduces those risks a little bit more.
Garrett: Why UEFI secure boot is difficult for Linux Posted Jan 18, 2012 23:11 UTC (Wed) by stumbles (guest, #8796) [Link] Or boot off a live CD and go about your business.
Garrett: Why UEFI secure boot is difficult for Linux Posted Jan 19, 2012 7:39 UTC (Thu) by ekj (guest, #1524) [Link]
That *is* a form of secure boot: It works if you're absolutely certain that the code that starts the computer, reads in the boot-block on the CD-ROM and executes it, does so in a secure manner and could not be subverted.
If there's a possibility that this code is subverted, all bets are off.
Garrett: Why UEFI secure boot is difficult for Linux Posted Jan 19, 2012 13:53 UTC (Thu) by drag (subscriber, #31333) [Link]
Also if your boot loader checks the signature on the kernel and the initrd then you can use the initrd to verify the rest of your system using file-based IDS.
This had the advantage over a live cd system in that it's automatable and is easier for the OS vendor to support.
Garrett: Why UEFI secure boot is difficult for Linux Posted Jan 18, 2012 17:50 UTC (Wed) by drag (subscriber, #31333) [Link]
They won't get their keys added.
What you'll have to do is take advantage of "custom mode" to allow a user/installer to use their own keys. This mode is described in the kernel.
As far as 'boot loader' malware, it's not rare to install data into the MBR to make it easier for your virus (or whatever) to re-infect a machine.
The latest Windows malware I have had the misfortune to run into latched itself into the NT kernel's block driver stack at the lowest level. It had the capability of creating new subvolumes on the root file system and installing itself to that. This little trick meant that even formatting the file system and re-installing Windows wasn't enough to get rid of it permanently (although it was not clear if it could somehow re-install itself in a new installation. It doubt that would be possible unless it hooked into the MBR or something like that).
Garrett: Why UEFI secure boot is difficult for Linux Posted Jan 18, 2012 17:57 UTC (Wed) by drag (subscriber, #31333) [Link]
> This mode is described in the kernel.
uck. I meant "This mode is described in the article".
|
|||||||||||||