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.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2012-06-15 02:30 am (UTC)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.
Trusted Boot
Date: 2012-06-15 06:30 am (UTC)Re: Trusted Boot
Date: 2012-06-15 08:31 pm (UTC)no subject
Date: 2012-06-15 11:06 am (UTC)- Early implementations of any such system are likely to contain significant security flaws before the system reaches maturity.
- Secure boot only adds security if people use it as well as all their existing precautions, not instead.
- It's dangerous for a security system to be billed as offering more protection than it in fact does, and it seems likely that'll happen once marketing gets hold of this.
- When commercial decisions align the interests of those wanting to run Linux on particular hardware with the interests of bad people, the Linux community may invent countermeasures of interest to bad people with surprising rapidity.
Certainly, I'd prefer to say that secure boot can add security, not that it does add security.Can vs Does
Date: 2012-06-15 01:18 pm (UTC)Hardly a worthwhile distinction. Take for example a bank vault. It adds security as long as the bank robbers don't have an access code, or they don't have the bank manager's granddaughter hostage. I don't think you can say any security measure *does* add security, merely that it *can* add security.
Re: Can vs Does
Date: 2012-06-16 12:38 pm (UTC)As I said, there are foreseeable risks that could turn it into something that caused more problems than it solved. They're easily avoided at the technical level, but I fear commercial concerns might interfere.
no subject
Date: 2012-06-15 04:36 pm (UTC)What's not clear to me is whether there are the *other* threat models involved. Those are, for example, firmware support/assistance for DRM, nonremovable malfeatures foisted on the user by the OS vendor or their government, the threat of non-secure boot being removed (limiting the freedom of the user to run arbitary kernel code of their own devising). I think a lot of people want clarification of what's _not_ possible with secure boot.
no subject
Date: 2012-06-15 08:35 pm (UTC)Please
Date: 2012-06-15 05:04 pm (UTC)Re: Please
Date: 2012-06-15 08:35 pm (UTC)Re: Please
Date: 2012-06-16 09:09 am (UTC)Re: Please
Date: 2012-06-16 09:43 am (UTC)Re: Please
Date: 2012-06-16 05:38 pm (UTC)Re: Please
Date: 2012-06-16 10:22 pm (UTC)Re: Please
Date: 2012-06-22 07:42 pm (UTC)Re: Please
Date: 2012-06-16 10:01 am (UTC)Why not TPM?
Date: 2012-06-16 12:02 am (UTC)Sorry if you've already addressed this.
Best/Liam
Re: Why not TPM?
Date: 2012-06-16 02:09 am (UTC)Re: Why not TPM?
Date: 2012-06-19 02:53 pm (UTC)Re: Carla Schroder
Date: 2012-06-16 11:16 pm (UTC)Security for whom?
Date: 2012-06-17 01:40 am (UTC)Re: Security for whom?
Date: 2012-06-17 01:54 am (UTC)Re: Security for whom?
Date: 2012-06-17 04:21 am (UTC)I agree with Ben: "Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety."
Re: Security for whom?
Date: 2012-06-17 12:03 pm (UTC)Giving up liberties
Date: 2012-06-17 02:52 pm (UTC)Even the ability to to add my own keys is just a feel-good item if I cannot remove/replace *all* other keys. Those other keys will still allow access whether I wish it or not.
Re: Giving up liberties
Date: 2012-06-17 05:14 pm (UTC)It's about the implementation really
Date: 2012-06-17 07:50 pm (UTC)Security vs no security doesn't even enter the picture at this point.
A question about secure boot usefulness
Date: 2012-06-19 04:37 am (UTC)So my question is this: if we have locked down access to kernel mode in this way, doesn't that mean that no malware would be able to rewrite the bootloader in the first place? This seems to make the initial root of trust part of the system unnecessary - we could just have a non-buggy kernel that refuses to load unsigned code into kernel mode, and refuses to allow usermode to update the bootloader. It doesn't matter that malware could load at boot, because malware never gets the chance to rewrite the bootloader.
If there are kernel bugs that allow access to kernel mode, then the malware doesn't need to worry about installing itself in the bootloader - it can just rewrite some startup file to re-exploit the kernel at every boot, and once it's in the kernel it can hide its presence and prevent any updates from being installed.
Re: A question about secure boot usefulness
Date: 2012-06-19 03:00 pm (UTC)But yes, your point is valid. On its own secure boot doesn't provide much additional security. But it does permit the creation of a secure environment - you can put something like dm-verity on top of that in order to ensure that your userspace is trusted.
theory vs practice
Date: 2012-07-23 08:49 pm (UTC)Lets come back in 1~2 years and we will see if i'm right. What is certain is that it will add a hurdle for anyone who wants to try different software on their PC.
cheers
Re: theory vs practice
Date: 2012-07-23 08:52 pm (UTC)