[personal profile] mjg59
Carla 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.

Date: 2012-06-15 02:30 am (UTC)
From: (Anonymous)
Amen to that last point. If you want to argue against something, be prepared to back up your arguments with facts. Otherwise, your opponent has a ready-made excuse to ignore everything you say.

Date: 2012-06-15 04:30 am (UTC)
From: (Anonymous)
While it might not make sense to say secure boot adds no security, it seems perfectly reasonable to say that secure boot adds very little security in exchange for a significant inconvenience and an architecture that enshrines a gatekeeper.

It's very limited in scope

Date: 2012-06-15 10:14 am (UTC)
From: (Anonymous)
As near as I can tell, secure boot is limited to making sure your kernel hasn't been tampered with.

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-20 04:50 pm (UTC)
From: (Anonymous)
Ever heard of a MBR rootkit son?

MBR rootkits are barely on the radar in industry

Date: 2012-06-20 08:18 pm (UTC)
From: (Anonymous)
Sure, I've heard of MBR rootkits, and they are at the very bottom of the threat list.

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)
From: (Anonymous)
I'll readily admit that I have only a cursory knowledge about the inner workings of secure boot, but from my reading there is no mechanism for any OS to assert that it has booted securely. The only informative mechanism is an in-memory flag that can be trivially provided by a subversive boot element.

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)
From: (Anonymous)
"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."

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)
From: (Anonymous)
Does the secure boot specification contain a (mandatory) hardware failsafe that prevents an unsigned firmware from being written by a compromised OS?

Re: assumption of innocence

Date: 2012-06-19 12:41 pm (UTC)
From: (Anonymous)
Thanks, that's good to know

Re: assumption of innocence

Date: 2012-06-19 12:59 pm (UTC)
From: (Anonymous)
But that's not really true, as there is debsums and/or rpm -V. You don't need to trust the underlying components as long as you can observe them independently.

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-21 02:03 pm (UTC)
From: (Anonymous)
My response wasn't about the kernel issue, I was referring to your assertion that there is "no way for the OS to prove that the PAM stack hasn't been replaced".

But there is, since the OS can execute processes in parallel with the PAM stack (e.g. init, sulogin) which can independently observe it.

Only a small hurdle

Date: 2012-06-27 01:09 pm (UTC)
From: (Anonymous)
What's the basis for saying that it adds very little security?

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)
From: (Anonymous)
Are there any plans of implementing Trusted Boot or TXT in general?

Date: 2012-06-15 11:06 am (UTC)
gerald_duck: (Default)
From: [personal profile] gerald_duck
While everything you say seems reasonable, my experience of previous security systems is that there are some concerns to raise that you've not mentioned:
  • 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)
From: (Anonymous)
"Certainly, I'd prefer to say that secure boot can add security, not that it does add security."

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)
gerald_duck: (Default)
From: [personal profile] gerald_duck
I think you're considering can/does in any individual case. My point is that secure boot might represent an overall reduction in security, on average, across all deployments.

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.

Date: 2012-06-15 04:36 pm (UTC)
From: [identity profile] pjc50.livejournal.com
Security implies a context and a threat model. It's clear that one of the threat models secure boot is intended to protect against is boot sector viruses; even if you subvert the running operating system, it's extremely hard to install a compromised OS, shim loader, or virtualisation layer in the way. So this should at least force malware to stay in userland where it can be cleaned up more easily, or to re-attempt to exploit the kernel on reboot.

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.

Please

Date: 2012-06-15 05:04 pm (UTC)
From: (Anonymous)
C'mon, man. You can't claim secure boot offers security without testing actual implementations. Maybe you're a genius and you've considered all possible side effects? For example, if I run Windows and get a virus which alters the Windows kernel, what happens when I reboot? If the result is that I can not boot, then it is not unreasonable for someone to think secure boot is broken by design. On the other hand, one might think this is a feature, since it is preferable not to boot a compromised OS. I think many home users are of the former type, and will panic if they can't start their computers. I recently cleaned up some viruses on a relative's computer, and I could surf the net just fine with or without them present.

Re: Please

Date: 2012-06-16 09:09 am (UTC)
From: (Anonymous)
But this is impractical. Instead of downloading a free antivirus program to cure a virus, Windows users now have to spend $99 at the geek squad to turn on their computers. It makes no sense to lock a person out. Why can't I just restart the computer with the network plug removed? It is MY computer, isn't it? A simple warning on boot would be sufficient. This could be more about large copyright holders maintaining control than security. A brief history of Microsoft should make a reasonable person suspicious.

Re: Please

Date: 2012-06-16 05:38 pm (UTC)
From: (Anonymous)
What if recovery media is not provided? You're being too optimistic in relying on past practices which are being discontinued (for example, Apple OS upgrades are mostly done over the net now). More importantly, you won't address why it's even necessary to lock a person out of their own computer. Your blind faith in secure boot sounds to me like a garden-variety anti-progessive stance, without any good evidence. Those GNU zealots are so unreasonable, aren't they!

Re: Please

Date: 2012-06-16 10:22 pm (UTC)
From: (Anonymous)
Actually, if my parents' computers were to be compromised, I would very much prefer that their computers refuse to boot. Keeping their credit card details safe is pretty important in my book. Temporarily unable to boot vs Permanent monetary loss. I know which one I pick.

Re: Please

Date: 2012-06-22 07:42 pm (UTC)
From: (Anonymous)
We could provide (unwritable?) rescue images...? :)

Re: Please

Date: 2012-06-16 10:01 am (UTC)
From: (Anonymous)
Will forcing everyone to wear blindfolds and handcuffs on airplane improve security? Of course! Just same as "secure" boot.

Why not TPM?

Date: 2012-06-16 12:02 am (UTC)
From: (Anonymous)
It's not clear to me what advantage Secure Boot offers over a TPM verified boot process.
Sorry if you've already addressed this.

Best/Liam

Re: Why not TPM?

Date: 2012-06-19 02:53 pm (UTC)
From: [identity profile] pjc50.livejournal.com
If you've seen the reaction to secure boot, imagine the hostile reception to TPMs.
(screened comment)

Security for whom?

Date: 2012-06-17 01:40 am (UTC)
From: (Anonymous)
I agree that secure boot really does add security. The problem is I am not convinced that I, the computer "owner", am not one of the things that is being protected against.

Re: Security for whom?

Date: 2012-06-17 04:21 am (UTC)
From: (Anonymous)
Technically, you are correct so long as those options actually available to me. For many, however, those options can be made effectively unavailable.


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)
From: (Anonymous)
Except that you aren't really giving up any liberties here.

Giving up liberties

Date: 2012-06-17 02:52 pm (UTC)
From: (Anonymous)
Am I not? How so? Currently, I have complete control over my boot process/firmware. Under secure boot I cede that control to someone else who decides what I will be allowed to do.

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.

It's about the implementation really

Date: 2012-06-17 07:50 pm (UTC)
From: (Anonymous)
I certainly didn't take away the "encourages everyone to ignore those legitimate concerns" from the article. There are many ways that one could implement secure boot type of functionality that wouldn't give a single entity absolute power over your hardware. UEFI secure booting has to be the worst thought out solution to the problem in existence. It certainly wasn't a system designed for the benefit of the end customer in mind. Comparing it to SSL encryption for banking or kernel flaws seems really silly.

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)
From: (Anonymous)
It seems that for Secure Boot to be effective, access to kernel-mode must be entirely locked down - kernels and drivers must all be signed, because if a signed kernel can be subverted by malware then the malware can simply use that signed kernel as part of its boot-time takeover.

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.

theory vs practice

Date: 2012-07-23 08:49 pm (UTC)
From: (Anonymous)
You can debate the theory. But in practice we all know that this thing isn't going to prevent Windows 8 piracy, and that it IS going to be circumvented, probably in multiple ways. Point me out an existing piece of hardware with signed or locked code that hasn't eventually been cracked.

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

Profile

Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at Nebula. Member of the Linux Foundation Technical Advisory Board. Ex-biologist. @mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer.

Page Summary

Expand Cut Tags

No cut tags