No, really, secure boot does add security
Jun. 14th, 2012 08:39 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59Carla Schroder wrote a piece for linux.com on secure boot, which gives a reasonable overview of the technology and some of the concerns. It unfortunately then encourages everyone to ignore those legitimate concerns by making the trivially false claim that secure boot is just security theatre.
Security isn't some magic binary state where you're either secure or insecure and you can know which. Right now I'd consider my web server secure. If someone finds an exploitable bug in Apache then that would obviously no longer be the case. I could make it more secure by ensuring that Apache runs in a sufficiently isolated chroot that there's no easy mechanism for anyone to break out, which would be fine up until there's also a kernel exploit that allows someone to escalate their privileges enough to change their process root. So it's entirely possible that someone could right now be breaking into my system through bugs I don't even know exist. Am I secure? I don't know. Does that mean I should just disable all security functionality and have an open root shell bound to a well known port? No. Obviously.
Secure boot depends on the correctness of the implementation and the security of the signing key. If the implementation is flawed or if control of the signing key is lost then it stops providing security, and understanding that is important in order to decide how much trust you place in the technology. But much the same is true of any security technique. Kernel flaws make it possible for an unprivileged user to run with arbitrary privileges. Is user/admin separation security theatre? SSL certificate authorities have leaked keys. Is it security theatre for your bank to insist that you use SSL when logging in?
Secure boot doesn't instantly turn an insecure system into a secure one. It's one more technology that makes it more difficult for attackers to take control of your system. It will be broken and it will be fixed, just like almost any other security. If it's security theatre, so is your doorlock.
Why is this important? Because if you tell anyone that understands the technology that secure boot adds no security, they'll just assume that you're equally uninformed about everything else you're saying. It's a perfect excuse for them to just ignore discussion of market restrictions and user freedoms. We don't get anywhere by arguing against reality. Facts are important.
Security isn't some magic binary state where you're either secure or insecure and you can know which. Right now I'd consider my web server secure. If someone finds an exploitable bug in Apache then that would obviously no longer be the case. I could make it more secure by ensuring that Apache runs in a sufficiently isolated chroot that there's no easy mechanism for anyone to break out, which would be fine up until there's also a kernel exploit that allows someone to escalate their privileges enough to change their process root. So it's entirely possible that someone could right now be breaking into my system through bugs I don't even know exist. Am I secure? I don't know. Does that mean I should just disable all security functionality and have an open root shell bound to a well known port? No. Obviously.
Secure boot depends on the correctness of the implementation and the security of the signing key. If the implementation is flawed or if control of the signing key is lost then it stops providing security, and understanding that is important in order to decide how much trust you place in the technology. But much the same is true of any security technique. Kernel flaws make it possible for an unprivileged user to run with arbitrary privileges. Is user/admin separation security theatre? SSL certificate authorities have leaked keys. Is it security theatre for your bank to insist that you use SSL when logging in?
Secure boot doesn't instantly turn an insecure system into a secure one. It's one more technology that makes it more difficult for attackers to take control of your system. It will be broken and it will be fixed, just like almost any other security. If it's security theatre, so is your doorlock.
Why is this important? Because if you tell anyone that understands the technology that secure boot adds no security, they'll just assume that you're equally uninformed about everything else you're saying. It's a perfect excuse for them to just ignore discussion of market restrictions and user freedoms. We don't get anywhere by arguing against reality. Facts are important.
no subject
Date: 2012-06-15 04:30 am (UTC)no subject
Date: 2012-06-15 05:20 am (UTC)It's very limited in scope
Date: 2012-06-15 10:14 am (UTC)I know boot sector viruses were common back in the 80s when everybody had to stick floppy disks in drives that happened also to be the default boot device, but is this really a problem nowadays?
So it seems to be addressing a threat that doesn't actually exist.
Re: It's very limited in scope
Date: 2012-06-15 08:29 pm (UTC)Re: It's very limited in scope
Date: 2012-06-20 04:50 pm (UTC)MBR rootkits are barely on the radar in industry
Date: 2012-06-20 08:18 pm (UTC)In a high value target system, you've already been completely owned before the attacker can even think about installing anything into the MBR. Boot attacks are like slicing the upholstery in a car you've already stolen.
For individuals, sure, boot attacks (especially in systems running windows) are an issue. For a bank? Not really, food poisoning in the cafeteria is a bigger threat.
assumption of innocence
Date: 2012-06-15 01:58 pm (UTC)When I read the title of your post, I was hoping that you would clarify the method with which an OS can assert its secure-boot status, because as I see it, secure boot is mere sophistry: you start from a presumed-secure base, then erect big and inconvenient obstacles to try and maintain that assumption.
But how does the OS prove the base was secure to begin with?
Re: assumption of innocence
Date: 2012-06-15 03:56 pm (UTC)Secure firmware is flashed at the factory and can only be re-flashed with signed updates. Obviously if the firmware is compromised it can just lie to the OS and say that the boot is secure when in fact is not.
Re: assumption of innocence
Date: 2012-06-15 06:14 pm (UTC)Re: assumption of innocence
Date: 2012-06-15 08:31 pm (UTC)Re: assumption of innocence
Date: 2012-06-19 12:41 pm (UTC)Re: assumption of innocence
Date: 2012-06-15 08:30 pm (UTC)Re: assumption of innocence
Date: 2012-06-19 12:59 pm (UTC)In the case of secure boot, that independent observation can't come from the machine itself, because by definition it cannot be trusted. But I wonder if LOM techniques combined with corporate network management wouldn't be able to provide verifiable security?
Re: assumption of innocence
Date: 2012-06-19 02:34 pm (UTC)Re: assumption of innocence
Date: 2012-06-21 02:03 pm (UTC)But there is, since the OS can execute processes in parallel with the PAM stack (e.g. init, sulogin) which can independently observe it.
Re: assumption of innocence
Date: 2012-06-21 02:09 pm (UTC)Only a small hurdle
Date: 2012-06-27 01:09 pm (UTC)Boot-level malware authors already have several hurdles to clear; typically involving luring you into doing something dangerous in the first place (say, getting you to click on a pdf), finding probably several 0-day or commonly unpatched exploits (say, to make their way from the PDF you clicked into Acrobat, and then from Acrobat into the operating system), and so on. What Secure Boot does is add one more hurdle.
The question is, how big is this hurdle, and how much will it reduce the effectiveness / increase the cost to the malware authors?
If x86 were like ARM, where MS is not going to sign anyone else's binaries, then I'd say it certainly will make things much more secure. In that case, the only way to install a bootsector rootkit would be to get MS's signing key, which is presumably going to be very difficult.
However, with MS offering to sign developer's binaries, the whole thing goes out the window. Suppose that someone (either a lone hobbyist or a group of smaller distros working together) sign an extlinux binary that allows you to boot arbitrary kernel. Now all the malware author has to do, after breaking through Adobe and into the running kernel, is put that signed extlinux binary in and configure it to boot his malware. Or, suppose that a number of anti-virus vendors have signed bootloaders on their CDs, so you can boot and "securely" clean your system. If any of these are not perfectly secure, he can use one of these. In the worst case, he can use one of the identities he's stolen in a previous heist (or purchased on the black market) to create a Verisign account to sign his own binary.
Maybe all of these attacks are actually infeasable; if so, you need to make a case for that.
But assuming they are feasible: Is that an extra hurdle? Sure. But it's a really small one compared to all the others. If the other hurdles didn't deter or prevent the malware author, why would this one do so? It probably wouldn't extend the cost to make a boot-sector rootkit more than a day at most.
To make an analogy: Suppose that you are filthy rich and own a gigantic diamond. (Or you're an evil scientist and you're keeping the secret of your power.) When not on display / in use, it's in your vault in the 5th level underground, with alarms and massive doors and lasers and floor pressure sensors and everything. But you think the guy from Mission Impossible is planning on stealing it. So you ask your security expert, and he suggests that in addition to all that, you put your treasure in a small safe. What would you think of that? Technically, it does add security, because it does add one more hurdle to the secret agent breaking in. But practically, it's not even worth thinking about, because if he's already gotten through the vault door, the lasers, and the pressure sensitive floor, the small safe is going to be a cakewalk.
That's what it seems like the current x86 implementation of SecureBoot is: a very small additional hurdle to a determined attacker who has already cleared several hurdles much more difficult. And one which does so at a terrible cost to the freedom of users.