|
|
Log in / Subscribe / Register

Practical security for 2014

Practical security for 2014

Posted Jan 10, 2014 13:50 UTC (Fri) by paulj (subscriber, #341)
In reply to: Practical security for 2014 by nix
Parent article: Practical security for 2014

You don't even need to subvert the firmware to get a persistent exploit. Even if:

1. The firmware is non-subvertable
2. The firmware boots a known, signed OS (e.g. SecureBoot)

The signed OS can *still* be persistently subverted at runtime if:

a. There exists a privilege escalation bug in the signed OS
b. There exists a privilege escalation bug in the signed OS involving the automatic parsing of some data (e.g. configuration).
c. That data can be persistently modified (i.e. you can modify/add files)

Anyone who has followed security news over the years would be unlikely to want to wager much on the non-existence of b, and a and c definitely exist.

Just signing the static code that booted is *not enough* to give you a guarantee that your signed OS can not be persistently modified. Claiming, e.g., SecureBoot can do so is just fundamentally wrong.

to post comments

Practical security for 2014

Posted Jan 10, 2014 16:40 UTC (Fri) by raven667 (subscriber, #5198) [Link] (144 responses)

> Just signing the static code that booted is *not enough* to give you a guarantee that your signed OS can not be persistently modified. Claiming, e.g., SecureBoot can do so is just fundamentally wrong.

I hope no one who knows about SecureBoot is making the claim that the OS kernel can't be exploited after booting because SecureBoot definitely doesn't make that security claim, it's clearly ludicrous as you point out. Each step in the process though that can have verification of the next step in the process before executing it pushes out the frontier of what can be modified and what can be claimed to be pristine. This is why the next step after SecureBoot is to have the kernel do modification checking of modules before loading them, and to close off the normal administrative access to modify the running kernel if you choosing to use SecureBoot. The further you push out the frontier the more you have control over how and when a persistent compromise can be run, because it has to use normal OS facilities to do so, and you should be safely able to replace the stored kernel with one which fixes the exploit, breaking the persistent compromise. The best the compromise can do it block the update which hopefully is user-visible.

SecureBoot doesn't make your system magically invincible, it just closes the doors on a few places where persistent compromises can hide, hopefully pushing them to more visible and easily detectable spots. Peripheral firmware is another place where malware can hide and is something that SecureBoot doesn't attempt to fix, there would need to be new technologies and standards to start trying to tackle the problem of compromised peripheral firmware.

Practical security for 2014

Posted Jan 10, 2014 17:06 UTC (Fri) by paulj (subscriber, #341) [Link] (143 responses)

Not exploit, but *persistent* exploit - i.e. one that persists after a reboot. The way this LWN article is reporting what mjg59 has said suggests that mjg59 may be claiming that SecureBoot prevents an exploit from persisting across a reboot:

“To protect our users, Matthew said, we have to protect the entire software chain. So, for example, boot-time software verification, as implemented by UEFI secure boot, is an absolute requirement. Operating systems are too big to be perfect; they will be compromised over time. But the worst case is a compromise that can become persistent. Verification of system software before booting it can protect against that possibility.”

It depends on how you read "protect". I don't know which way mjg59 meant that, but SecureBoot does not stop persistent exploits if the system has any modifiable data read automatically by the system.

I agree with nix that SecureBoot is a lot of complexity for very little gain. The security benefits, so far as Linux users are concerned, are mostly snake-oil. SecureBoot can not attest that you have booted into a unexploited system, because SecureBoot only attests to the *starting state* of the OS, and the major problem we have with the common OSes today is that the *executing state* (post starting state) is so easy to subvert.

SecureBoot doesn't fix the gaping security chasms in the OSes used and, if you fixed the OSes to be secure, SecureBoot would be moot. At least as far as the owner of the machine is concerned.

To me, the only people who benefit from SecureBoot are those who gain leverage over the market, and over less sophisticated users, by holding the signing keys, and their favoured associates.

Practical security for 2014

Posted Jan 10, 2014 17:14 UTC (Fri) by raven667 (subscriber, #5198) [Link] (137 responses)

> SecureBoot doesn't fix the gaping security chasms in the OSes used and, if you fixed the OSes to be secure, SecureBoot would be moot. At least as far as the owner of the machine is concerned.

You don't judge a fish by how well it climbs trees.

Practical security for 2014

Posted Jan 10, 2014 17:32 UTC (Fri) by paulj (subscriber, #341) [Link] (136 responses)

And you don't secure a house by using a super-strong mortar between the foundation and the first set of bricks.

I suspect we've strayed off into argumentum ad vehiculum territory.

Practical security for 2014

Posted Jan 11, 2014 5:26 UTC (Sat) by drag (guest, #31333) [Link] (135 responses)

Well..

Unless you know what software you are running then how well it's designed is fairly moot question.

'Trusted boot' system's goal is only to really establish the fact that the software you are running is really the software that is supposed to be running. It can do a little bit to reduce the attack surface by adding in features like signed drivers and whatnot, but it can't really do anything to magically make insecure software secure.

Unfortunately for us PC firmware authors are terrible at writing software. The fact that UEFI is FUCKING HUGE and extremely complex is not helping any. Combine that with the fact that it's closed source and then it's pretty much a nightmare. There is no bottom you can trust.

Seems to me that if you really have critical life-and-death-level things you want to keep secret/secure/validated then consumer hardware is a no-go.

I suspect nowadays that if you really want to have a machine that is truly secure you are going to have to start off with one of those open source ARM toy systems. Something were every flash module is programmable by you and you can control the boot process from the very beginning. I know those powerful SoCs are complex and it's never going to be absolutely perfect, but I think that it's massive improvement over what we have now with PCs. At least then you have a fighting chance.

Practical security for 2014

Posted Jan 11, 2014 8:15 UTC (Sat) by paulj (subscriber, #341) [Link] (133 responses)

But you know what software you're running because you installed it. The only reason there could be a doubt what software you're running is if your software is so insecure it can be subverted without your knowledge (this is the case for all common PC OSes).

If it is the case that your OS is swiss-cheese at runtime - then knowing you booted the *right* swiss-cheese buys you pretty much nothing.

On the other hand, if your OS can't be subverted at runtime, then you don't need to worry about booting the wrong sofware.

SecureBoot is one of those areas where I feel the traditional "defence in depth" argument for security doesn't apply. It is just fundamentally incapable of defending against OS exploits. Which makes me suspect SecureBoot is about something else - "defending" against unsophisticated users changing their their own system software on their own hardware. The PC architecture is now just one bit-flip away from this, and MS owns that bit, and certain entities in the Linux world have willingly helped erect this infrastructure.

Practical security for 2014

Posted Jan 11, 2014 18:56 UTC (Sat) by drag (guest, #31333) [Link] (132 responses)

> But you know what software you're running because you installed it.

Only right after you installed it.

If your machine is compromised then it may or may not be the same software you used. There is now way from userspace to prove that the kernel code you are running has not been compromised since it depends on the kernel to do it.

> The only reason there could be a doubt what software you're running is if your software is so insecure it can be subverted without your knowledge (this is the case for all common PC OSes).

Yes and the idea of 'trusted boot' is that you can do this by a reboot. Rather then pull the storage and check the checksums or other bothersome approach.

> On the other hand, if your OS can't be subverted at runtime, then you don't need to worry about booting the wrong sofware.

If you are running a system for a number of years, how can you be sure of this?

At least with a 'trusted boot' setup you can install a new version of the kernel (or some drivers) that patch security bugs and with the use of signed binaries you can know that it's the kernel you actually are running after a reboot.

> It is just fundamentally incapable of defending against OS exploits.

That's not it's purpose. It has a specific function.

Might as well claim that sha512sum is fundamentally incapable of defending against OS exploits, so it's completely pointless to use checksums.

> "defending" against unsophisticated users changing their their own system software on their own hardware.

Maybe, but that is a utterly and completely unrelated issue. That is a problem of who controls the keys, not the fact that the keys exist.

Practical security for 2014

Posted Jan 11, 2014 20:39 UTC (Sat) by paulj (subscriber, #341) [Link] (131 responses)

It sounds like you believe SecureBoot mitigates or even fixes the problem of having your OS compromised. I don't believe your belief is safe, neither in theory nor in practice.

Yes, if your machine is compromised, it's no longer the same software. How does SecureBoot help you? It lets you boot your swiss-cheese software - why on earth do you think it won't get compromised again? Why do you think there won't be any bugs in privileged, automatically run system code in things like, e.g. parsing configuration data, or dealing with (ever more commonly used) IPC from tools that are reading configuration data? (Systemd recently had a local root exploit CVE related to DBus and Polkit). Or it could have been a remote exploit of a network service, and the system will be as vulnerable!

With SecureBoot, the kernel can't be changed anymore. Other binaries potentially still can be - I don't think distros check binary signatures yet, but let's assume that will be put in place soon. This then shifts persistent attacks from replacing boot-path privileged code to attacking privileged, automatically-run parsers (e.g. of config data or IPC with other non-privileged tools that might read config data).

Parsers (data/IPC) in privileged system code have not had their reliability tested up till now, because it didn't matter much before. Experience suggests (including my own with my own software ;) ) that this means they are all likely *full* of exploitable bugs.

All SecureBoot achieves is shifting the goalposts slightly for *some* attackers (some attackers don't care about persistence). We've singularly failed at writing secure kernels. There's simply no good basis to think we're going to fare any better at writing secure userspace code.

The systems will be just as exploitable, persistently. All that will be achieved is:

1. To add a layer of complexity that fails to achieve any practical goals for end-users, other than tautological ones ("Well, it was never meant to achieve X - it was meant to check the signature of the kernel being booted, and boy does it do that well!").

2. Being generous, to buy perhaps a month or two, while the attackers update their tools, where persistent exploits are less available to kiddies.

3. Helped build and popularise the infrastructure such that the line between end-users having the freedom to install their own software on future hardware, and them being at the mercy of corporate interests as to what is allowed, is down to 1-bit of information under the control of Microsoft.

If you want systems to be secure against persistent exploits, you first need *secure software at runtime*. If you have a way to be sure of that, you have no need to lock it down. If you don't have runtime security, then boot-time attestation buys you *nothing*. And yes, we're not going to achieve the required run-time security any time soon, certainly not with mutable systems.

To make SecureBoot really work, you'd have to have it verify *all state* (configuration, etc.). Good luck with that.

Practical security for 2014

Posted Jan 11, 2014 21:46 UTC (Sat) by raven667 (subscriber, #5198) [Link] (130 responses)

> It sounds like you believe SecureBoot mitigates or even fixes the problem of having your OS compromised. I don't believe your belief is safe, neither in theory nor in practice.

Again that's not the claim which is being made, so the SecureBoot people agree with you that it doesn't fix the problem of your OS being compromised post-boot.

> With SecureBoot, the kernel can't be changed anymore. Other binaries potentially still can be - I don't think distros check binary signatures yet, but let's assume that will be put in place soon. This then shifts persistent attacks from replacing boot-path privileged code to attacking privileged, automatically-run parsers (e.g. of config data or IPC with other non-privileged tools that might read config data).

So you do understand the claim being made. This is exactly right, the intent described by SecureBoot is to push persistent attacks from replacing code in the boot path to attacking the OS sometime after boot, it's there to provide a beach head.

> Parsers (data/IPC) in privileged system code have not had their reliability tested up till now, because it didn't matter much before. Experience suggests (including my own with my own software ;) ) that this means they are all likely *full* of exploitable bugs.

Yep, but now this problem is worth solving and there is a better defined attack surface. Also these exploitable bugs can be fixed, even in compromised systems, the only way for an exploit to prevent this is to block the update, which is possible to detect, it can't modify the update to keep the hole open.

> All SecureBoot achieves is shifting the goalposts slightly for *some* attackers (some attackers don't care about persistence).

Yep. Well to be more precise there were no goalposts before because anything could be permanently jimmied undetectably and there was nothing you could do about it but put the whole thing a chipper and walk away.

> you first need *secure software at runtime*.

That's totally, 100% impossible. Not even worth talking about. What is worth talking about is likely risks and risk mitigation, not the absence of risk.

> boot-time attestation

It doesn't attest to anything, it just allows each step in the boot process to check the next step, and SecureBoot is only itself checking the first step, the bootloader. The rest of the checking is the bootloader checking the kernel, the kernel checking all of its inputs before executing them and so on and so on. The risk is how confident can you be in the checking at each stage, the earlier stages are simpler to audit, later stages become more complex and riskier until the kernel is up and running user code at which point you are nearly 100% at risk for shenanigans.

An audit of the initrd, module loading and any config parsing done in early boot would be the next step. Checking the init and having init check it's helpers and configs would be the next. Over many many years you may be able to systematically reduce the places where this kind of stuff can hide and make it easier to spot and clean.

Or maybe the next attack direction is to jimmy various firmwares such as on GPUs or hard drives and try and use them to attack the kernel or system firmware. That will require new techniques to be accreted and the wheel turns again.

> And yes, we're not going to achieve the required run-time security any time soon, certainly not with mutable systems.

If you are thinking that 100% runtime security is a prerequisite then since that is not an achievable goal therefore no runtime permission checking would ever make sense. I don't buy into that, I'm more interested in risk management, risk is modified by what techniques are known, what is popular at any given time, ease of detection and mitigation, etc. SecureBoot moves this from being 100% guaranteed to be F'd to only being 98% F'd with a chance of not being F'd, or a chance to fix it.

Practical security for 2014

Posted Jan 11, 2014 22:39 UTC (Sat) by paulj (subscriber, #341) [Link] (5 responses)

Then what is the practical system security goal for SecureBoot? (Other than the tautologous-ish "Verify the code being loaded is what is meant to be"). You agree that this shifts the goal-posts to next code being run. You agree that code can never be made secure (and, again, it isn't even safe to think that code can converge /toward/ being secure, as our systems get more complex and more featureful), hence may I presume you would agree the resulting system is still persistently subvertable?

In which case, what exactly was the point of the SecureBoot?

I disagree the goal-posts have been shifted to a reduced attack surface. The attack surface is quite large compared to the kernel, and we've made *no progress* on improving the overall security of the latter. Again, you agree that software can not be made secure¹, yet you're pinning your hopes on making the SecureBooted software secure!

Where is your chance of not being fucked? You can only be basing this on there (maybe) not existing tools today to persistently subvert the system through data-reading attacks. If that is true, that is only because the tool-makers havn't needed to do this yet. There is no good reason to think this step will trouble the rootkit tool-makers, once they need to take that step.

There's a massive amount of very wishful thinking going on in those who think SecureBoot is going to buy anything beyond the most short-term of an edge. Maybe a somewhat similar kind of wishful thinking to what I had when I first installed an early rootkit-checker (that was maybe useful for a short time, a very short time, then the rootkit makers adapted). ;)

1. I disagree a little with this. At least, I think the rampant insecurity of system software today could be massively improved with better tools and programming languages. Never perfect, but certainly a lot better than today's situation of system software being written in C/C++ (or running on interpreters written in C/C++), on hardware that can do very little checking of things.

Practical security for 2014

Posted Jan 12, 2014 0:10 UTC (Sun) by raven667 (subscriber, #5198) [Link] (4 responses)

> I disagree the goal-posts have been shifted to a reduced attack surface. The attack surface is quite large compared to the kernel, and we've made *no progress* on improving the overall security of the latter. Again, you agree that software can not be made secure¹, yet you're pinning your hopes on making the SecureBooted software secure!

I believe that computers cannot be made 100% secure, but things can be made more or less secure and that SecureBoot makes forward progress toward more secure. There are fewer attack paths and less trusted code as each step gets the chance to verify the next, it isn't all blindly trusted with no way to verify.

> Where is your chance of not being fucked? You can only be basing this on there (maybe) not existing tools today to persistently subvert the system through data-reading attacks. If that is true, that is only because the tool-makers havn't needed to do this yet. There is no good reason to think this step will trouble the rootkit tool-makers, once they need to take that step.

Its true that there is almost certainly data-driven exploitable vulnerabilities in the initial setup but as that code is tested they should become more rare. This early boot code doesn't have as much churn as the totality of the kernel (drivers, filesystems, etc.) so I think that in this limited subset of code that bugs can be fixed faster than they are created, although you can never be sure you've got them all.

> Maybe a somewhat similar kind of wishful thinking to what I had when I first installed an early rootkit-checker (that was maybe useful for a short time, a very short time, then the rootkit makers adapted). ;)

There are very clear problems with running such tools on a system which is already subverted. There are fewer problems if you can run these tools before the system is subverted. There is a continuum of probability that your system is subverted, lesser in early boot when there is very little security critical code and easier verification and higher the more of the system comes up, highest when you start running un-verified code. You'll have to balance the chance that there is an unknown vulnerability in early boot config code which subverts system startup before you can get a clean single-user mode up, presuming you build a path of verification all the way from the boot loader to your security checking tools.

Practical security for 2014

Posted Jan 12, 2014 10:09 UTC (Sun) by paulj (subscriber, #341) [Link] (1 responses)

I believe that computers cannot be made 100% secure, but things can be made more or less secure and that SecureBoot makes forward progress toward more secure. There are fewer attack paths and less trusted code as each step gets the chance to verify the next, it isn't all blindly trusted with no way to verify.

Ah, I see, you think you're reducing the amount of exploitable code. That's not what's happening though. As I explained before, what happens instead is that SecureBoot *elevates* the security sensitiveness of a *large* bunch of code that was never security-sensitive before (parsers and external event handling code in privileged code). To think that the system security will somehow be *increased* by this is utterly misguided. Particularly as we've seen, and continue to see, a large of parsing and event handling code (IPC) added to privileged code to make Linux more dynamic and reactive.

We simply do not know how to reliably write secure system software in C/C++, I think you'd agree. The LWN security page has been a testament to this. Even highly security sensitive software that gets much attention tends to see repeated problems (e.g. the kernel). That previously non-sensitive, non-attacked code is somehow going to be more secure seems highly, highly unlikely. And that user-space system software isn't exactly smaller in scope than the kernel either!

Anyway...

Practical security for 2014

Posted Jan 12, 2014 10:25 UTC (Sun) by paulj (subscriber, #341) [Link]

Oops, that code would have been security-sensitive before, for local exploits. Sorry. It just becomes even more of a target, for persistence.

So /non-sensitive/, /less-sensitive/. Etc.

Practical security for 2014

Posted Jan 12, 2014 10:19 UTC (Sun) by paulj (subscriber, #341) [Link] (1 responses)

This early boot code doesn't have as much churn as the totality of the kernel (drivers, filesystems, etc.) so I think that in this limited subset of code that bugs can be fixed faster than they are created,

This is just a lack of imagination. It just has to be code that will be automatically run at *some point*. Not just early boot code. It could be a privileged daemon that is intended to allocate some resources/permissions when a user requests. Rest assured the attackers will not limit themselves this way.

Further, I don't buy that early boot code has little churn in it. In Fedora we've seen a number of different re-engineerings of the initrd over the years. We've had a significantly more complicated PID 1 put in place, which speaks IPC with various things, some ultimately with paths for user influence.

You can have your belief that bugs in even just early-boot code will converge toward 0, but I still think this is incredibly wishful thinking and counter to general historical evidence, both in that there has been significant churn in boot code, and that the only reliable property of software is that it will be buggy! :)

Practical security for 2014

Posted Jan 12, 2014 16:00 UTC (Sun) by raven667 (subscriber, #5198) [Link]

> This is just a lack of imagination.

Maybe, I'm a deeply boring person 8-)

> In Fedora we've seen a number of different re-engineerings of the initrd over the years.

This churn is more in the programs which auto-generate the initrd and not the the part of the kernel which reads it.

Practical security for 2014

Posted Jan 11, 2014 23:09 UTC (Sat) by paulj (subscriber, #341) [Link] (123 responses)

Oh, on your initrd audit comment - see my "You'd have to have SecureBoot check all mutable state. Good luck with that" comment before. :)

Every bit of mutable state that might end up affecting privileged, automatically run code will have to be validated in some way - the state and/or the code. Just for initrds, you're looking at hardware description state (both "all known hardware" databases, and of the machine), disk labels and UUIDs. Any state you can't validate, you must validate the code that might see it instead (which means you need to identify that code). You might be faced with having to limit the flexibility of the end-user/machine-owner, because of validation problems. That's surely a massive, massive project to do for Linux.

I'm not sure, but I think it'd be easier to first do more research on how to build system software where that software and any external state is designed to be more amenable to validation (static and runtime), then use the lessons learnt to engineer a system from scratch to meet those goals. (And we're both agreed that still won't be perfect, security-wise).

Basically, I think both Windows and Linux are write-offs with respect to security, because of how they were and are engineered. ;) However, they both do still have *general programmability and flexibility* going for them (for now). I just don't see the point in giving up that general programmability for most users (other than exploit experts and script-kiddies) for a security goal that is either so narrow as to be useless ("Yay, my compromised system at least booted the right code!") or is not actual deliverable (i.e. making the system more immune to exploits).

SecureBoot doesn't give you or I a Secure computer. It *does* give me a more restricted and less flexible computer though, with added complexity and bugs!

Why would I want that? You could only want that if you thought it did give you a more Secure computer. However, everyone who suggests this is the case seems to quickly fall back "Well, it's not meant to do X - it just secures the boot" when you try get the details of exactly how it does that. :)

Practical security for 2014

Posted Jan 12, 2014 1:06 UTC (Sun) by dashesy (guest, #74652) [Link] (5 responses)

I think the most interesting attack would be one that compromises the SecureBoot (wait will happen give it time), then injects the BluePill code and then closes the vulnerability after itself :)
You really believe your bootloader is verified but it is not. Secure boot is a gimmick created by Microsoft to counter the mac-vs-PC commercials, to sell people on the idea of a finally secure Windows, that will not have malwares, while really making the OS more secure to partially back the plan.

Practical security for 2014

Posted Jan 12, 2014 2:07 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

Right now this kind of malware doesn't even need to exploit anything.

Practical security for 2014

Posted Jan 12, 2014 2:29 UTC (Sun) by dashesy (guest, #74652) [Link] (3 responses)

No, but can be detected and removed much easier.

Practical security for 2014

Posted Jan 12, 2014 3:02 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

How? Short of booting from an external media a perfect rootkit would be undetectable.

Practical security for 2014

Posted Jan 12, 2014 4:05 UTC (Sun) by dashesy (guest, #74652) [Link] (1 responses)

Easier, not easy.
While auditing a dis-assembly of a ROM in old BIOS is something an over-suspicious (or critically targeted) agency may endeavor, same task with all the complexity of secure boot is doubly crazy. Also if one could get suspicious of rootkit activity (battery consumption, CPU noise, suspicious network access, ...) in non-secure boot, same activity could be just attributed to the complexity of SecureBoot and ignored, assuming that all is safe because OS booted fine, and so the chain must be secure. The false sense of security.
From practical point of view, if it is harder for OS (and BIOS vendors) to get it right (look at all the problems resulting in non-working systems), then it will be just as hard to validate every once in a while by an audit.

Practical security for 2014

Posted Jan 12, 2014 16:10 UTC (Sun) by raven667 (subscriber, #5198) [Link]

> Also if one could get suspicious of rootkit activity (battery consumption, CPU noise, suspicious network access, ...) in non-secure boot, same activity could be just attributed to the complexity of SecureBoot and ignored, assuming that all is safe because OS booted fine, and so the chain must be secure.

I'm sorry but that's total baloney, I don't think anyone but you would try to attribute suspicious network activity, high battery consumption and high CPU usage to the bootloader code having a signature validated before it was run when the system booted.

Practical security for 2014

Posted Jan 12, 2014 16:49 UTC (Sun) by raven667 (subscriber, #5198) [Link] (116 responses)

> Every bit of mutable state that might end up affecting privileged, automatically run code will have to be validated in some way - the state and/or the code.

Yep. To get the most out of it you'll want to take years of effort and go after each vector, making sure that your input is valid, etc. Regardless, fixing these attack vectors is still a worthwhile effort, the kernel team is keen on fixing any bugs which allow you to wrest control away from the kernel, but SecureBoot provides a name to it and a priority order of things to check.

Some of this I'm sure is already done, at least for the more well traveled parts of the kernel, things like filesystem data structrures, disk labels, UUIDs were identified as attack vectors for drive by media insertion a long time ago and so it's harder to find bugs in these areas than it was 5+ years ago.

> engineer a system from scratch

That's just not going to happen any time soon. Maybe in 2030 we can talk about a new from the ground up effort to build a new computing ecosystem but I don't think that's ever going to happen, at least its not foreseeable to me. I wouldn't be surprised to see some direct decedent of Linux still in active use in 2050. The shared ownership of the kernel and the inherent mutability of it means that its far more maintainable than any software project of similar complexity ever created before by a single company.

> ... giving up that general programmability ...
> ... more restricted and less flexible computer ...

I'm not sure what you mean here, SecureBoot only provides for signature checking of the UEFI firmware and bootloader code, nothing more. You can turn it off or load your own keys into it or put in static hashes. In what way does it give up general programmability or make your computer more restricted and less flexible? I would agree if we were talking about a boot locked computer like you see in the mobile phone ecosystem, I understand that the technology for both is the same but the difference in policy is a _fundamental_ difference.

> give you a more Secure computer. However, everyone who suggests this is the case seems to quickly fall back "Well, it's not meant to do X - it just secures the boot" when you try get the details of exactly how it does that. :)

Well you probably get that because you seem to expect much much more from this than what it's capable of giving. Without the tool of SecureBoot it's trivially easy for a rootkit to take over your system to the point that only dedicated offline forensic analysis of the hardware could find it, there is nothing that even tries to prevent this. With SecureBoot you are encoding a policy and trying to keep the malware out of some of the common rocks it hides under and flushed out so that it is more exposed.

> Yay, my compromised system at least booted the right code!

At some point before the kernel is re-exploited the system isn't compromised yet and the kernel is giving you accurate data about what is on the filesystem, etc. For example if you can get to your initrd before the malware is given a chance to run (as there are a limited number of defined ways code can be run before the system is compromised) then you can do your own forensic analysis on the computer and find the malware, or a script can do that for you, before the malware has a chance to hide itself after compromising the kernel.

That may seem a more modest goal than having a Secure Computer, just getting to the initrd before the malware has a chance of re-exploiting the system, but I think that is achievable to get there with 95% confidence. That's a matter of opinion so feel free to disagree 8-). Even better would be able to get to running systemd before the malware can run, forcing the malware to launch using standard code paths where it is highly visible. That may be an impossible dream 8-)

Practical security for 2014

Posted Jan 14, 2014 15:13 UTC (Tue) by paulj (subscriber, #341) [Link] (115 responses)

Look, I'm not saying getting rid of security holes in the OS isn't worth doing. I do think this just keeps us at, at best, a stable-ish number of security holes, with the set of holes very slowly changing over time (when holes are patched, not infrequently the code concerned is quite old).

You've described SecureBoot as a beach-head, allowing the initial binaries booted to be "secure" - that is, known to be the same binary as before (which doesn't actually guarantee "secure", NB). You're putting your faith in that this is getting you something:

At some point before the kernel is re-exploited the system isn't compromised yet and the kernel is giving you accurate data about what is on the filesystem, etc. For example if you can get to your initrd before the malware is given a chance to run (as there are a limited number of defined ways code can be run before the system is compromised) then you can do your own forensic analysis on the computer and find the malware, or a script can do that for you, before the malware has a chance to hide itself after compromising the kernel.

But again, you're ignoring that the binary is just one piece of the system that will be exploited - the other part of the system is state. Even the kernel and initrd will parse and act on persistent, modifiable state during boot. From information supplied by the BIOS/firmware (OK, your EFI may be signed - but have the variable contents been?), to disk layout information (you really think there's no more holes there? :) ).

However, let's give you a "clean" initial boot. How often are you going to pause the boot in your initrd and take the time to check the system is secure? Also, what benefit did all that complexity give you over booting from separate media (USB/CDROM) to run this check? Your environment is still basically off-line - you've just saved 1 reset cycle - you can't rely on the rest of the system, but can continue to boot into it.

That's a lot of complexity to get the security equivalent of having your kernel and initrd on a RO floppy or CD (I actually had a machine booting this way for years ;) ). Except, whether I was allowed to fiddle with the write-protect tab wasn't in the hands of MS for future hardware, or the competence/capriciousness of vendors for current hardware (which has bitten nix, as per other comments).

You are claiming that security benefits of booting kernel & initrd from media that is RO to attackers are high. Yet pretty much no one bothered to do this as standard practice with floppies or CDs. Why not, if the benefits were so great? Indeed, as you havn't mentioned relying on this technique and being glad that SecureBoot makes it a little easier to manage, I presume you didn't either! :)

Next, I'll note *again* that we're shoving ever more complex functionality up into PID 1. Code that is active from very, very early boot has become the nexus for adding system features, and churn. I just don't buy into your vision of an early-boot beach-head composed of simple, rarely-touched code, sorry. :)

Practical security for 2014

Posted Jan 14, 2014 15:30 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (114 responses)

"But again, you're ignoring that the binary is just one piece of the system that will be exploited - the other part of the system is state."

And yes, obviously there will be bugs there. And those bugs will be fixed. Secure Boot gives us a mechanism to ensure that those bugfixes can be applied even if the system is compromised, which otherwise would not be the case.

"Why not, if the benefits were so great?"

Because it made performing security updates painful, and an attacker could just rewrite CMOS to force a boot off hard drive instead.

Practical security for 2014

Posted Jan 14, 2014 15:35 UTC (Tue) by paulj (subscriber, #341) [Link] (54 responses)

Bugs may be fixed, but the number of bugs will not converge toward 0. Particularly not when early-boot are regularly being re-engineered and expanded. To suggest otherwise flies in the face of wide-spread industry experience.

Practical security for 2014

Posted Jan 14, 2014 15:47 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (53 responses)

No, but the set of actively exploited bugs tends to be bounded. The current state of affairs is that a single successful attack against your system can be turned into a persistent compromise - even if you fix the original bug, your system is still under the control of the attacker. Secure Boot provides mechanisms to ensure that that's not true. The attacker can no longer subvert the boot process itself, so has to compromise some other component. But once we know that that component has a vulnerability, we can fix it and upgrade it from within the trusted environment.

This can only be bypassed if there's an exploitable vulnerability in the code within the trusted environment. That's ok, though, because we can make the set of code we need to trust almost arbitrarily small. There's no need to trust the on-disk /sbin/init - just download a new one.

Is making it significantly more difficult for an attacker to engineer a persistent compromise of a system an improvement of security? Obviously. Does Secure Boot provide a mechanism for doing so? Yes.

Practical security for 2014

Posted Jan 14, 2014 16:20 UTC (Tue) by paulj (subscriber, #341) [Link] (25 responses)

The current state of affairs is that a single successful attack against your system can be turned into a persistent compromise - even if you fix the original bug, your system is still under the control of the attacker. Secure Boot provides mechanisms to ensure that that's not true.

Just for the record, this claim for SecureBoot is patently incorrect. Any exploit of incorrectly handled persistent state (e.g. config or other policy files, hardware database files) will remain persistent, as discussed before.

The notion that these attacks can not affect early boot, and that we are capable of building a very small and near perfectly reliable "trusted" subset of the OS is highly, highly optimistic.

Practical security for 2014

Posted Jan 14, 2014 16:28 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (24 responses)

"Just for the record, this claim for SecureBoot is patently incorrect. Any exploit of incorrectly handled persistent state (e.g. config or other policy files, hardware database files) will remain persistent, as discussed before."

Nonsense, because Secure Boot ensures that we have a mechanism to perform updates of the affected components without having to parse that persistent data with vulnerable software.

Practical security for 2014

Posted Jan 14, 2014 16:42 UTC (Tue) by paulj (subscriber, #341) [Link] (23 responses)

Sure, if you know about the exploit. Are you claiming SecureBoot provides us with omniscience?

Even for known exploits, SecureBoot need not protect against it, because (for the umpteenth time), the binary that gets booted is but *part* of the input that determines the state of computation. The other parts are the non-code state, which is often modifiable, and is always key to any exploit.

E.g., it is quite plausible a kernel could have a bug that allows it to be subverted by reading a modified filesystem (to pick one kind of state kernels tend to have to parse), such as the one that the system resides on. Now riddle me this, where is your secure system to run your update code from?

Then there is the hypervisor attack, if your system was subverted before, how can code within it *ever again* reliably detect between running on metal and running in a hypervisor? I know you dismiss this as leading to user-detectable slowness but not everyone believes that (not all systems have local users, and someone here has already mentioned knowledge of in-the-wild hypervisor attacks).

Practical security for 2014

Posted Jan 14, 2014 16:44 UTC (Tue) by paulj (subscriber, #341) [Link] (11 responses)

(the answer to the riddle is, of course, that you have to boot from alternative, known good media with a fixed kernel - just like before, despite SecureBoot).

Practical security for 2014

Posted Jan 16, 2014 14:27 UTC (Thu) by pjones (subscriber, #31722) [Link] (10 responses)

The part you've missed is that it's possible to create a persistent exploit across *reinstalls* without Secure Boot. In that case, known good media will not help you. With Secure Boot it will.

Practical security for 2014

Posted Jan 16, 2014 14:34 UTC (Thu) by paulj (subscriber, #341) [Link] (9 responses)

What type of exploit would persist across a reinstall without SecureBoot, yet not with?

Practical security for 2014

Posted Jan 16, 2014 17:42 UTC (Thu) by pjones (subscriber, #31722) [Link] (8 responses)

So the basic principle is that a rootkit installs itself as the bootloader and replaces the firmware interfaces with its own copies. Those interfaces would appear to be the same as the original ones, except they'd hide the "bootkit" from you, and present what appears to be a pristine machine to do an installation on.

It really isn't /that/ much code on a UEFI machine. You have to replace GetVariable(), SetVariable(), and GetNextVariableName() with wrappers that hide your boot entries, and you have to wrap the BlockIo driver (i.e. the block device driver in UEFI) that the EFI System Partition is being read with, so as to hide the real boot device your exploit is booting off of. The harder part is hiding it from the OS, but that's still entirely possible, since you can intercept the OS as it is loaded.

This sort of thing isn't new any more; with relatively low levels of sophistication these kinds of "bootkits" already exist. Secure Boot stops this attack.

Practical security for 2014

Posted Jan 16, 2014 17:52 UTC (Thu) by paulj (subscriber, #341) [Link] (7 responses)

Why would a reinstall not reinstall the bootloader, or at least verify what it is? That's only a part-reinstall, and yes, of course, that would leave the system vulnerable - agreed.

Practical security for 2014

Posted Jan 16, 2014 18:06 UTC (Thu) by pjones (subscriber, #31722) [Link] (5 responses)

The whole point is that when it reinstalls the boot loader and sets a new boot order, it's telling the "bootkit" code the new boot order, rather than the real system firmware. The bootkit code is then able to persist in the boot path in front of the newly installed OS.

Practical security for 2014

Posted Jan 16, 2014 19:01 UTC (Thu) by paulj (subscriber, #341) [Link] (4 responses)

Ah, I see. That stems then from a choice made to have UEFI services remain resident and overrideable, it seems. SecureBoot could make that secure, or you could avoid relying on code in the system, mutable by prior boots (as was my point ;) ).

Practical security for 2014

Posted Jan 16, 2014 20:13 UTC (Thu) by raven667 (subscriber, #5198) [Link] (3 responses)

That particular method of causing a rootkit to persist is not unique to uEFI and is has been done with BIOS for some time now. The next version of that kind of exploit is probably going to be centered around device firmware (running on the device, not device driver uEFI modules running on the CPU) rather than modifying the uEFI firmware, if uEFI firmware becomes difficult to modify remotely.

Practical security for 2014

Posted Jan 16, 2014 22:35 UTC (Thu) by paulj (subscriber, #341) [Link] (2 responses)

If I understand pjones correctly, the persistent attack in the UEFI services override case is from a disk-loaded bootloader.

In the BIOS case, at least for a long time, the BIOS EPROM was hardware write-protectable (I suspect the motivation there was more for board makers to minimise returns due to kiddies needlessly updating it than security), and the BIOS could be set to run directly from the ROM. Not bad protection. Booting from alternative media couldn't be bypassed by a bootloader on disk with a write-protected BIOS EPROM.

Without write-protection of the firmware, you're hosed, I completely agree! :)

I agree SecureBoot can give you sufficient write-protection. However, I dislike that it won't necessarily be me who says what can be written. I prefer a write-protect system that can't possibly be under anything but my control.

(To make this easy, the BIOS blobs often had a well-defined structure, and it was possible to unpack them and add your own code in - the old Award BIOS certainly did. Then there was some kind of PC convention to allow option ROMs to be recognised via some magic number, and entry points automatically get called. I forget the details, but I did this once to stuff PXE-capable etherboot code for my for my option-ROM-less NIC into my BIOS as an option ROM, so I could still get a network boot ;). This kind of firmware hacking is now disallowed with SecureBoot, isn't it?).

Practical security for 2014

Posted Jan 17, 2014 16:30 UTC (Fri) by raven667 (subscriber, #5198) [Link] (1 responses)

> I agree SecureBoot can give you sufficient write-protection.

Then I'm not sure what we've been talking about because it seems like you agree.

> However, I dislike that it won't necessarily be me who says what can be written. I prefer a write-protect system that can't possibly be under anything but my control.

SecureBoot is under control of the person at the console, it can be disabled or have keys added or removed. I think for the purposes of our discussion the fact that some vendors produce boot locked hardware (Apple IOS devices, MS WinRT and WinPhone, many Android, Tivo, etc.) just doesn't exist in our universe because that's not a general purpose computer and isn't running Fedora or whatever. The fact that SecureBoot is more like the Chromebook model, where you can run a factory-signed image, or you can take control and run whatever you want, however you want, except in the SecureBoot model, we can continue to use the security infrastructure to provide integrity checks on boot.

Practical security for 2014

Posted Jan 17, 2014 16:47 UTC (Fri) by paulj (subscriber, #341) [Link]

Initially I did not agree SecureBoot provided the same security as booting from alternative, good media because I had never heard of this network-boot check thing which Matt described in the comments that it is still to be implemented. The article covering Matt's talk doesn't mention it, so I guess it wasn't a widely known issue (?). Once that's implemented I agree it potentially could provide the same guarantees. However, it's also possible there'll be practical issues that might affect that. We'll have to see.

As SecureBoot distro implementations stand today though, they're do not stop all persistent attacks.

Practical security for 2014

Posted Jan 16, 2014 20:09 UTC (Thu) by raven667 (subscriber, #5198) [Link]

I think you have far more faith in a compromised machine than what the SecureBoot people do.

Practical security for 2014

Posted Jan 14, 2014 16:48 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (10 responses)

"Sure, if you know about the exploit. Are you claiming SecureBoot provides us with omniscience?"

No, but in general actively exploited vulnerabilities get noticed.

"Now riddle me this, where is your secure system to run your update code from?"

It boots a kernel that doesn't have that bug. Really, this isn't difficult.

"if your system was subverted before, how can code within it *ever again* reliably detect between running on metal and running in a hypervisor?"

How did you get the bootloader to launch an unsigned hypervisor?

Practical security for 2014

Posted Jan 14, 2014 16:56 UTC (Tue) by paulj (subscriber, #341) [Link] (9 responses)

And how do you reliably install that fixed kernel from code running within a subverted system?

Are you saying end-users will be banned from running their own hypervisors under SecureBoot? Are hyper-visors going to go the way of kexec?

Also, if a kernel has a boot-time subvertable bug, how do you stop an attacker loading a hypervisor with that subversion?

Practical security for 2014

Posted Jan 14, 2014 17:09 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (8 responses)

"And how do you reliably install that fixed kernel from code running within a subverted system?"

The bootloader downloads and boots a fixed kernel. The bootloader is signed, so subverting the bootloader is difficult.

"Are you saying end-users will be banned from running their own hypervisors under SecureBoot? Are hyper-visors going to go the way of kexec?"

No, I'm saying that trivial hypervisors such as Blue Pill won't run under Secure Boot. Migrating a running system to something like KVM or Hyper-V is impractical.

"Also, if a kernel has a boot-time subvertable bug, how do you stop an attacker loading a hypervisor with that subversion?"

You don't, which is why your security upgrade mechanism shouldn't use that kernel.

Practical security for 2014

Posted Jan 14, 2014 17:25 UTC (Tue) by paulj (subscriber, #341) [Link] (5 responses)

Aha, so the bootloader has to do the updating now? Is that possible today with any Linux distro?

So now we need bootloaders with support for at least HTTP. It'll also need to store state somewhere for at least some basic config for network and distro parameters. At least some of those parameters will need to be validated somehow.The bootloader has to have what will likely be the exact same filesystem code (the bootloader-system-update may well be a special Linux system).

This isn't really getting any simpler, is it? :)

(This reminds me of Suns' "WANBoot", which was a bit of a beast last time I tangled with it.).

Practical security for 2014

Posted Jan 14, 2014 17:38 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (4 responses)

"Is that possible today with any Linux distro?"

Currently? No. But it's possible, which it wouldn't be without Secure Boot.

"So now we need bootloaders with support for at least HTTP."

Which we already have.

"It'll also need to store state somewhere for at least some basic config for network and distro parameters."

In most cases that's going to just be built into the bootloader, but it could be overridden via EFI variables.

"The bootloader has to have what will likely be the exact same filesystem code"

The bootloader doesn't need to touch any filesystems for this.

"This isn't really getting any simpler, is it? :)"

Yes, it is.

Practical security for 2014

Posted Jan 14, 2014 17:51 UTC (Tue) by paulj (subscriber, #341) [Link] (1 responses)

You think network boot isn't possible without SecureBoot? (Fairly sure some systems have jumper write-protectable CMOS for boot order btw).

How are you going to protect the state in those EFI variables btw?

(I mentioned Solaris WANboot before, and securing it was a major PITA, AFAIR).

Practical security for 2014

Posted Jan 14, 2014 18:12 UTC (Tue) by mjg59 (subscriber, #23239) [Link]

Network boot is possible without Secure Boot, but you'd need infrastructure to support that network boot (which most consumers won't have) and you'd need a mechanism to ensure that system configuration can't be modified (I've never seen a system that had hardware protection for CMOS - there's no trivial way to implement that in most cases).

Boot-services EFI variables can't be modified at runtime.

Practical security for 2014

Posted Jan 14, 2014 17:52 UTC (Tue) by paulj (subscriber, #341) [Link] (1 responses)

Why does the bootloader not need to touch the filesystem? I thought the point was to update the system on filesystem?

Practical security for 2014

Posted Jan 14, 2014 18:09 UTC (Tue) by mjg59 (subscriber, #23239) [Link]

You wouldn't do the actual update from the bootloader, the bootloader would simply be the trusted mechanism for obtaining a known-good kernel and initramfs for performing the actual update.

Practical security for 2014

Posted Jan 17, 2014 23:52 UTC (Fri) by Jandar (subscriber, #85683) [Link] (1 responses)

> Migrating a running system to something like KVM or Hyper-V is impractical.

The hypervisor jailhouse does such a migration from a running system as described in LWN.

Practical security for 2014

Posted Jan 18, 2014 21:59 UTC (Sat) by mjg59 (subscriber, #23239) [Link]

If you're migrating the running kernel as well as the running OS, it's not a problem.

Practical security for 2014

Posted Jan 14, 2014 16:26 UTC (Tue) by PaXTeam (guest, #24616) [Link] (25 responses)

> Does Secure Boot provide a mechanism for doing so? Yes.

for all the discussions that took place over the past year and more, you have yet to prove this. in fact many people showed you how false that claim is.

Practical security for 2014

Posted Jan 14, 2014 16:32 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (24 responses)

Add a boot-services variable that contains a date. On boot, if still in the secure environment, perform DHCP and call out to a remote server. If the returned value is a date more recent than the date in the variable, download a set of files, verify them and boot them rather than anything on disk. Permit them to install updates. That way you can run a set of upgrades without relying on anything on the local system other than the bootloader, which means you can fix any vulnerabilities that are being used to create a persistent exploit. Without Secure Boot the attacker simply replaces the bootloader in order to disable this functionality.

Practical security for 2014

Posted Jan 14, 2014 16:46 UTC (Tue) by paulj (subscriber, #341) [Link] (4 responses)

Wow, this SecureBooting gets more and more complicated! How do I SecureBoot the DHCP server btw?

Practical security for 2014

Posted Jan 14, 2014 16:49 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (3 responses)

Your counterargument now involves an attacker being able to compromise your DHCP server in addition to your system, and you *don't* think there's any additional security there?

Practical security for 2014

Posted Jan 14, 2014 17:04 UTC (Tue) by paulj (subscriber, #341) [Link] (2 responses)

There is additional security, if you assume the security of the DHCP server is independent of the security of the subverted DHCP client. This is not always the case, particularly when they're both the same OS - in that case, the subversion of the client may mean the DHCP server is prone to the exact same subversion!

The boot from known-good, known-fixed media has far less complexity and is far more reliable.

Practical security for 2014

Posted Jan 14, 2014 17:12 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (1 responses)

"if you assume the security of the DHCP server is independent of the security of the subverted DHCP client"

Which ought to be a pretty safe assumption - the only network-facing code they should have in common is the kernel, and if your DHCP server has remotely-exploitable kernel vulnerabilities then you're already having a bad time.

"The boot from known-good, known-fixed media has far less complexity and is far more reliable."

And involves physical intervention every time you want to perform a security update. Good luck selling that idea.

Practical security for 2014

Posted Jan 14, 2014 17:44 UTC (Tue) by paulj (subscriber, #341) [Link]

And involves physical intervention every time you want to perform a security update. Good luck selling that idea.
Not every time. Only for updates that are known to require it. And your answers on the benefits of SecureBoot all have assumed that the impact of the exploit is known. We're talking about a small subset of all updates.

I've worked in or with a number of different corporate setups over the years, from small, to medium, to global, with various mixes of proficiencies. Even with the one corporate that was extremely technically proficient and who defaulted to remote boot & management of computers, they still required on site tech for interventions, and they still couldn't always get remote boot & management to provide required flexibility or always work correctly. It turns out to require ongoing expertise - especially if you want Internet booting. This isn't cheap.

For quite a few small to medium corporates I've seen, having local hands to intervene is *cheaper* than hiring in people sufficiently expert to make remote boot work well. Those local hands will already be there! Indeed, in an era of cut-backs, it may be the lesser-skilled "hands on" IT people who are less likely to be chopped than the network/server experts. The former will *always* be required, while the functions of the latter can increasingly be outsourced (Google Apps, etc).

Setting up & maintaining complex remote boot and update systems that may require knowing how to generate & sign SSL certs, versus inserting a USB stick in each computer, on the rare occasion. The former is not automatically cheaper in terms of labour than the latter, from what I have observed in business. The opposite in fact, by far the opposite.

Practical security for 2014

Posted Jan 14, 2014 17:30 UTC (Tue) by PaXTeam (guest, #24616) [Link] (18 responses)

and how is this elaborate scheme, bleeding from so many wounds, "making it significantly more difficult for an attacker to engineer a persistent compromise of a system"? it seems to me that we have very different ideas about what 'significantly' and 'persistent compromise' mean. maybe elaborate on yours?

also downloading GBs worth of data of an entire OS on each boot will surely do wonders on the corporate or home LAN never mind the internet if you were so brave to trust that. and then there're those pesky users who don't always have the luxury of a network connection, i guess they just should not reboot, did i get that right? ;)

next, i don't need secureboot to boot off a trusted medium (smart users of whole disk encryption have always been doing just that in fact).

next, how do you download fixes for vulnerabilities that noone knows about?

Practical security for 2014

Posted Jan 14, 2014 18:08 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (17 responses)

Without Secure Boot, is it trivial to elevate myself from root to a configuration where the system is (a) still compromised after a reboot without any further action on behalf of the attacker, and (b) impossible to recover without booting from external media? Yes. If I control the MBR, I control the entire OS.

With Secure Boot, things are more complicated. An attacker can't just replace the underlying boot components. And I now have a trusted environment that I can use to verify the system or perform updates without relying on the underlying system being in a good state.

This doesn't require transferring gigabytes of data. In most cases it'd be a single callout followed by a normal boot. In the worst case it'll be on the order of 20-30MB, plus the updates that you'd need to download anyway.

But yes, obviously, this isn't perfect. More work needs to be done to continue to improve overall system security. However, unless you're willing to go to lengths that are impractical in most deployments, you just can't implement anything like this without Secure Boot.

Practical security for 2014

Posted Jan 14, 2014 18:20 UTC (Tue) by paulj (subscriber, #341) [Link] (8 responses)

If your system is compromised, you don't have a trusted environment. You have a compromised environment that can tell your software anything.

Your counter-point to that depends on setting up some remote boot thing, which doesn't exist today and the ease-of-setup of which is unknown. If there's any setup required that's anything on the level of PXE booting or (heaven help us) WANBoot, then it'll be beyond a lot of lesser-skilled IT departments. In which USB stick / CDROM will be much easier, and SecureBoot didn't help.

Practical security for 2014

Posted Jan 14, 2014 18:26 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (7 responses)

"If your system is compromised, you don't have a trusted environment."

Yes, you do. The pre-boot environment is signed, trusted code with a sufficiently small attack surface that it's practical to audit.

"If there's any setup required that's anything on the level of PXE booting or (heaven help us) WANBoot, then it'll be beyond a lot of lesser-skilled IT departments."

Right, so there should be zero setup required, modulo privacy concerns that might require this to be opt-in. And, really, let's not focus on scenarios where you even have an IT department. Providing improved security for users who *don't* have professional security support is a significant win.

Practical security for 2014

Posted Jan 14, 2014 19:42 UTC (Tue) by raven667 (subscriber, #5198) [Link] (1 responses)

This kind of thing has already been done on EFI firmware on Apple hardware which can download the whole installer image and re-image a machine over wired or wireless without touching the local disk and is sufficiently user-friendly to be deployed to users without local IT support.

So just do that then. uEFI is a whole level beyond what PXE offers.

Practical security for 2014

Posted Jan 14, 2014 20:50 UTC (Tue) by mjg59 (subscriber, #23239) [Link]

The downside is that baking it into the firmware (as Apple have done) means it's not generalisable to other operating systems. Pushing it into the bootloader provides that extra flexibility, but then you need to trust your bootloader and hence Secure Boot.

Practical security for 2014

Posted Jan 14, 2014 22:32 UTC (Tue) by paulj (subscriber, #341) [Link] (4 responses)

The pre-boot environment is signed, trusted code with a sufficiently small attack surface that it's practical to audit.
So two things:

a) So SecureBoot of the main OS was irrelevant then, wasn't it? You've fallen back to booting some other system...

b) I'd be sceptical on that claim that this environment is small and auditable. Havn't looked at Intels' EFI sources - but how large are they, and have they actually been audited? GRUB and GRUB2 are also fairly hefty codebases and I doubt EFI would be any different, would it¹? If this network-update boot environment is written predominantly in C, and not written with validatable reliability as the first priority (rarely the case), I really wouldn't want to bet against someone with experience finding exploitable holes in O(days) of work².

I really do wonder if you're underestimating just how buggy system software is, even when written by *good* programmers and/or how easy it is for good security people to find ways to own code. You seem to have a *lot* more faith in the reliability of code than I have. But hey... ;)

1. Actually, let me dig up some numbers. For the Tianacore EDKII, generated using David A. Wheeler's sloccount tool: 


$ sloccount *
SLOC    Directory       SLOC-by-Language (Sorted)
600279  AppPkg          python=307690,ansic=292182,sh=407
213296  MdeModulePkg    ansic=210473,asm=2823
168207  EdkCompatibilityPkg ansic=140935,asm=17304,cpp=9919,pascal=49
160968  BaseTools       python=76701,ansic=73142,cpp=11091,sh=34
92118   MdePkg          ansic=84247,asm=7871
65831   IntelFrameworkModulePkg ansic=65388,asm=443
63116   NetworkPkg      ansic=63116
61390   StdLib          ansic=61152,asm=140,pascal=98
57635   ShellPkg        ansic=57635
35800   SecurityPkg     ansic=35744,asm=56
33184   DuetPkg         ansic=19542,asm=13262,sh=380
22985   ArmPkg          ansic=16316,asm=6563,pascal=106
19393   OvmfPkg         ansic=18619,asm=379,python=206,sh=189
19157   EmulatorPkg     ansic=16516,asm=2445,sh=196
17699   EmbeddedPkg     ansic=17389,asm=310
17380   ArmPlatformPkg  ansic=13388,asm=2446,pascal=823,python=638,sh=85
15748   OptionRomPkg    ansic=15748
15014   Nt32Pkg         ansic=14929,asm=85
9418    IntelFrameworkPkg ansic=9418
8022    UefiCpuPkg      ansic=5996,asm=1863,python=117,pascal=46
7464    CryptoPkg       ansic=7300,asm=93,sh=71
6493    SourceLevelDebugPkg ansic=5153,asm=1340
6181    Omap35xxPkg     ansic=6181
5339    PcAtChipsetPkg  ansic=5117,asm=222
2311    BeagleBoardPkg  ansic=2031,asm=185,sh=95
1699    PerformancePkg  ansic=1699
1288    StdLibPrivateInternalFiles ansic=1288
18      top_dir         sh=18
0       Conf            (none)
0       EdkShellBinPkg  (none)
0       EdkShellPkg     (none)
0       FatBinPkg       (none)
0       ShellBinPkg     (none)
0       UnixPkg         (none)


Totals grouped by language (dominant language first):
ansic:      1260644 (72.98%)
python:      385352 (22.31%)
asm:          57830 (3.35%)
cpp:          21010 (1.22%)
sh:            1475 (0.09%)
pascal:        1122 (0.06%)

$ sloccount MdeModulePkg/Universal
SLOC    Directory       SLOC-by-Language (Sorted)
40874   Network         ansic=40874
10218   HiiDatabaseDxe  ansic=10218
9862    Console         ansic=9862
9061    SetupBrowserDxe ansic=9061
6258    Acpi            ansic=5978,asm=280
5035    Variable        ansic=5035
4555    EbcDxe          ansic=4141,asm=414
4402    DisplayEngineDxe ansic=4402
3607    Disk            ansic=3607
3564    PCD             ansic=3564
2866    DebugSupportDxe asm=2070,ansic=796
2619    FaultTolerantWriteDxe ansic=2619
2273    PlatformDriOverrideDxe ansic=2273
1514    DriverSampleDxe ansic=1514
1360    CapsulePei      ansic=1360
771     MemoryTest      ansic=771
750     StatusCodeHandler ansic=750
697     SmbiosDxe       ansic=697
650     DebugPortDxe    ansic=650
629     ReportStatusCodeRouter ansic=629
335     CapsuleRuntimeDxe ansic=335
289     LockBox         ansic=289
182     FaultTolerantWritePei ansic=182
169     PcatSingleSegmentPciCfg2Pei ansic=169
145     LegacyRegion2Dxe ansic=145
121     WatchdogTimerDxe ansic=121
114     MonotonicCounterRuntimeDxe ansic=114
98      ResetSystemRuntimeDxe ansic=98
97      HiiResourcesSampleDxe ansic=97
77      SecurityStubDxe ansic=77
72      DevicePathDxe   ansic=72
70      TimestampDxe    ansic=70
52      Metronome       ansic=52
35      PrintDxe        ansic=35


Totals grouped by language (dominant language first):
ansic:       110657 (97.56%)
asm:           2764 (2.44%)
The AppPkg directory probably can be ignored, some example apps and a python interpreter, from a glance. Still, it does look like there's a hefty amount of non-trivial code, including hand-crafted, raw pointer, network protocol and disk format parsers amongst other things. Only a quick look at a couple of files, but it looks like fairly traditional C, that is historically known to result in lots and lots of security bugs, even when from the hands of the best programmers.

2. And note that someone finding an exploitable bug does not imply that knowledge will get to someone interested in fixing it any time soon. Sometimes I suspect the number of capable people looking for security problems greatly outnumbers those fixing them!

Practical security for 2014

Posted Jan 14, 2014 22:54 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (3 responses)

There's certainly plenty of code in the UEFI codebase, and a lot of it's certainly going to contain bugs. But very little of it handles untrusted input, and those paths have been audited much more heavily than the rest of the codebase.

Practical security for 2014

Posted Jan 14, 2014 22:57 UTC (Tue) by paulj (subscriber, #341) [Link] (2 responses)

What do you define as trusted v untrusted input? Remember, we're talking about a system which, in the previous boot, was subverted. Any and all state which that system could have modified can not be trusted any more (files, file system meta-data, etc).

Practical security for 2014

Posted Jan 14, 2014 22:58 UTC (Tue) by paulj (subscriber, #341) [Link]

Oh, and also, you're proposing to use the Internet to download stuff. So the network protocols in your trusted environment also need to be reliably free of bugs (IP, perhaps some ICMP, UDP, DHCP, TCP and HTTP, maybe more).

Practical security for 2014

Posted Jan 14, 2014 23:00 UTC (Tue) by mjg59 (subscriber, #23239) [Link]

Untrusted input is anything that cannot be proved to be trusted, so includes things like the PE/COFF binaries themselves (but not the executable code within), partition tables, the contents of the EFI system partition and so on.

Practical security for 2014

Posted Jan 14, 2014 22:00 UTC (Tue) by PaXTeam (guest, #24616) [Link] (7 responses)

> If I control the MBR, I control the entire OS.

not true at all. if this is the raison d'etre of this whole secureboot business then it failed right there.

> With Secure Boot, things are more complicated.

complicated - definitely. more secure - no proof for that.

> An attacker can't just replace the underlying boot components.

1. why would the attacker do that? (remember how i asked you for your understanding of 'persistent compromise'? there was a reason to that and you carefully avoided answering it.)

2. what 'boot components'? secureboot doesn't protect a plurality of them, it claims to provide 'something' (you called it 'significant' improvement in security) for one specific file *only*. *you* made claims that this was enough to ensure/derive this 'something' for further components (whatever they may be, we have yet to learn how much a 'persistent compromise' entails in your world ;).

> And I now have a trusted environment[...]

no you don't unless you want to redefine 'environment' as that one file that secureboot does 'something' for. in my world everything else is part of the environment and secureboot doesn't do 'something' for them.

> This doesn't require transferring gigabytes of data.

this comes down to that one question you so didn't want to answer so far. please, work that out first because everything seems to rest on it. what amount of data your scheme would require to be transferred depends specifically on how much data a 'persistent compromise' would potentially affect (and this is a trick question as the better persistent compromises in the real world don't even modify existing files so there would be nothing to restore, then what... ;). so far you seem to be going on an angle that this is something small whereas real life evidence and attacker creativity shows the exact opposite.

> However, unless you're willing to go to lengths that are impractical in most deployments,
> you just can't implement anything like this without Secure Boot.

what are all these impractical approaches 'in most deployments'? and what secureboot actually does is yet to be determined, so let's not use that as an argument for 'this is how security should be done' because so far all i saw was snakeoil and false sense of security.

Practical security for 2014

Posted Jan 14, 2014 22:46 UTC (Tue) by dlang (guest, #313) [Link]

Well, if you were to go all out on this the way Tivo does (queue hissing at evil company :-), you could be secure.

Tivo has the firmware check the signature of the kernel + initfs image, that filesystem then checks that the main OS hasn't been tampered with (nothing added, nothing removed, no changes)

But unless you are willing to lock a system down that far, which makes it unusable for anything other than an appliance, you aren't going to succeed

And even with a tivo-style lockdown, it only takes one flaw somewhere to let people in.

Practical security for 2014

Posted Jan 14, 2014 22:47 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (4 responses)

>> If I control the MBR, I control the entire OS.
>not true at all. if this is the raison d'etre of this whole secureboot business then it failed right there.

Wait. You're saying that if an attacker can install something into the MBR, they *don't* control the entire OS? That can't be what you mean.

I'm defining a persistent compromise as any attack that, without further action on the part of the attacker, will persist over system reboots and will not be removed by the standard security update mechanism (either because it's at a layer that security updates won't touch or because it's subverted or disabled the security update mechanism).

So let's assume that your system has been subject to an attack that has succeeded in installing such a persistent compromise. If it's sufficiently well written, the installed OS can no longer be trusted to give you reliable and accurate information regarding the contents of the drive or the running processes. You need to have some verified external environment to do this.

Booting from known-good media is one way to achieve this, but it requires physical presence and for you to have known-good media in the first place - most users are never going to go to the trouble. Worse, there's no easy way for the OS vendor to provide updates to said known-good media in order to automatically detect newly identified infections.

Secure Boot allows you to implement a mechanism in which you can define a policy to control whether or not the system downloads a small signed environment from your OS vendor and boots that rather than any OS on local storage. This is then able to perform updates (mitigating any persistent compromises that are implementing persistence by exploiting vulnerabilities in system components on each boot) and scan for fingerprints of other known compromises.

This obviously doesn't protect against unknown vulnerabilities or highly targeted attacks. That doesn't mean it's not an improvement. It would handle the majority of mass infections of home systems, which seems like something meaningful.

Practical security for 2014

Posted Jan 14, 2014 23:04 UTC (Tue) by paulj (subscriber, #341) [Link] (3 responses)

How often will you run this network-booted system checker? Every boot? Every week? Every month? Every year? It's going to be at least a few tens of MB in size amd take a noticeable amount of time to download over over-subscribed DSL links when they go to catch up on kitten pics in the evening when they've gotten home.

Home users are going to love this feature!

Practical security for 2014

Posted Jan 14, 2014 23:20 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (2 responses)

Whenever there's a vulnerability that's known to be actively exploited.

Practical security for 2014

Posted Jan 15, 2014 8:14 UTC (Wed) by paulj (subscriber, #341) [Link] (1 responses)

Which you can only check from this "secure" bootloader. So this won't work reliably and automatically for systems rarely rebooted (the system may be subverted to ignore any software update instructions to reboot).

Let's check back in a year or three and see if any distros have actually implemented anything like what you've described, and see what the practicalities of it are.

Practical security for 2014

Posted Mar 22, 2023 10:39 UTC (Wed) by paulj (subscriber, #341) [Link]

Checking back. None of this is implemented.

Practical security for 2014

Posted Jan 15, 2014 21:02 UTC (Wed) by nix (subscriber, #2304) [Link]

False sense of security? SecureBoot doesn't even provide *that*. What it provides to me is a true sense of *dread*, dread in the sense of 'this machine will be hell to set up and if I can't get SecureBoot to go away forever will be hell to upgrade every time as well'.

Practical security for 2014

Posted Jan 14, 2014 19:10 UTC (Tue) by hummassa (guest, #307) [Link]

> the set of actively exploited bugs tends to be bounded

Garrett, I respect you immensely, but WRT secure boot, your whole argument seems to rest on this premise... which I deeply doubt is true. Anyway, as secure boot is something that did not exist before and as the rest of your argument is voided if in fact (as I suspect) the set of actively exploited bugs is unbounded (Snowden documents, anyone?), it seems to me that the burden of proving this premise should be yours.

Practical security for 2014

Posted Jan 16, 2014 12:48 UTC (Thu) by paulj (subscriber, #341) [Link] (58 responses)

Note, if EFI makes boot-order immutable - as far as the system is concerned - then all the security benefits of SecureBoot can be achieved with EFI without SecureBoot by booting off write-only media, no? (I still think I once had an Abit motherboard with a jumper to make CMOS immutable though, but I could perhaps be mistaken).

The practical difference then is that SecureBoot provides a write-only-by-some media. The problem is who those "some" are. By default on PCs that's *not* the user/owner, and on some UEFI platforms (all ARM, and some PCs too) that option isn't open to the owner /at all/.

The other annoying bit is distros are stripping out useful features from the Linux they ship, when we've established there's no security benefit, but just to placate some theorised possibility that those features might annoy MS (kexec).

Practical security for 2014

Posted Jan 16, 2014 14:50 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (57 responses)

EFI does not make boot-order immutable. On x86 systems, the owner is free to take control of the system. kexec *is* a security issue (http://mjg59.dreamwidth.org/28746.html).

Practical security for 2014

Posted Jan 16, 2014 15:05 UTC (Thu) by paulj (subscriber, #341) [Link] (44 responses)

Sorry, I meant immutable to the running, normal system, if that wasn't clear. UEFI surely *must* do this, because you claimed booting from read-only media on an older BIOS system could be subverted by the running system changing CMOS to boot from other media, and this was a problem solved by SecureBoot¹.

If boot-order is also not protected in UEFI, then a subverted system could potentially arrange to boot the local system directly, bypassing the "boot a secure kernel via the Internet" boot-loader which you say is necessary. (Whether this is possible depends on the details of that bootloader - but none exist yet AFAIK, least as you've described). So, boot-order in UEFI systems surely must not be writeable from the OS, given what you've said before. (There are some EFI variables tweakable from the OS, iirc with my old Mac Mini and efivars, but presumably not boot order, given what you've said).

1. Equally, hardware manufacturers could have solved it with a physically write-protected boot-order, rather than SecureBoot. I think perhaps this has existed with PC boards before, but I'm not 100% sure.

Practical security for 2014

Posted Jan 16, 2014 15:17 UTC (Thu) by paulj (subscriber, #341) [Link] (36 responses)

E.g., here's one board that had a CMOS setup protection jumper (in addition to a flash ROM WP jumper - which was very common):

http://www.elhvb.com/mboards/chicony/ch880c/CH-880C.html

I'm almost sure my Abit Super7 board had something like that too.

Practical security for 2014

Posted Jan 16, 2014 15:32 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (35 responses)

No, it has a flash write protect jumper. It has nothing to protect the CMOS. How would you write-protect the CMOS? The clock needs access to it.

Practical security for 2014

Posted Jan 16, 2014 16:46 UTC (Thu) by paulj (subscriber, #341) [Link] (34 responses)

No, I didn't mean the flash write protect jumper. It also has: 

Setup Enable--J9E2

This jumper controls whether the CMOS Setup program can be run.

Pins 1-2 covered: users can run Setup. Access to CMOS is allowed
Pins 2-3 covered: Setup is disabled. Access to CMOS is provided

Whether that actually did electrically write-protect CMOS setup variables, I don't know. However, I don't think it's completely impossible to do so, while leaving the CMOS clock NVRAM writeable.

Practical security for 2014

Posted Jan 16, 2014 16:56 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (33 responses)

No, it simply disabled the hotkey→BIOS setup tool functionality. You'd still be able to modify CMOS contents through software.

"However, I don't think it's completely impossible to do so, while leaving the CMOS clock NVRAM writeable."

It's amazingly tedious having a conversation with someone who would prefer to discuss how they imagine the world works instead of spending some time figuring out how the world actually works. The datasheets for the RTC CMOS in Intel chipsets are publicly available. There's no write-protect bit or line.

Practical security for 2014

Posted Jan 16, 2014 17:01 UTC (Thu) by paulj (subscriber, #341) [Link] (32 responses)

Well, given there's a long line of answers from you in this thread that assume the existence of a non-existent bootloader, I'm entitled to the same feeling of tedium I guess.

Practical security for 2014

Posted Jan 16, 2014 17:17 UTC (Thu) by paulj (subscriber, #341) [Link] (3 responses)

Also, the board is an old 486 one. Boards then, as with my Abit, literally did have separate NVRAM on the board. Sheets for today's Intels chipsets with integrated NVRAM would not be relevant.

Practical security for 2014

Posted Jan 16, 2014 17:32 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (2 responses)

So look at the data sheet for a Dallas DS1387 and tell me how you'd implement a jumper that lets you write to the clock registers but not the rest of the CMOS registers.

Practical security for 2014

Posted Jan 16, 2014 18:00 UTC (Thu) by paulj (subscriber, #341) [Link] (1 responses)

At a glance, it seems to be trivial: have the jumper pull up ~WER. Shouldn't affect the RTC portion afaict.

Practical security for 2014

Posted Jan 16, 2014 18:03 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

WER is for the SRAM, not the CMOS. Boot order is stored in the CMOS. You could tie off WE instead, but now you can't update the clock registers either.

Practical security for 2014

Posted Jan 16, 2014 17:22 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (27 responses)

"Secure Boot is snakeoil" "Here's an example of how it can be used to provide a real improvement in security" "That can't possibly work because (spurious reasons based on an incomplete understanding of the problems, technology and incorrect beliefs about hardware)" look seriously what do you want? This functionality permits the creation of a secure mechanism for the validation and upgrading of user systems in the face of hostile code. The only alternative you've come up with involves read-only media and a CMOS-protection jumper that doesn't exist, which is clearly not practical for most home users.

Practical security for 2014

Posted Jan 16, 2014 17:43 UTC (Thu) by paulj (subscriber, #341) [Link] (26 responses)

I had never read before, until the comments in this thread, that SecureBoot requires a network stage "phone home" bootloader, which has yet to be implemented, to reliably achieve a SecureBoot. I'm not sure that's general knowledge either, but perhaps I havn't been paying attention. If it wasn't, this thread has been useful in drawing that out of you, and expanding on the implications.

Thanks for the ad-homimen. However, you've no idea whether or not those old boards CMOS WP jumper did or did not protect the NVRAM. I don't have a map of NVRAM handy to tell for sure, but if there's a sufficient gap between the BIOS setup variables and the area the OS still must write to, then it would be electrically quite feasible to pull up or down relevant address lines according to a jumper to prevent that BIOS config data being written to. Your assertion that CMOS jumpers weren't practical for home users runs contrary to the reality that home computers for a long time *did* often require fiddling with jumpers - even if they're not desirable today.

Given you're allowed to rely on non-existent technology in your arguments, I don't see why I should be denied the same opportunity in mine. I personally would have much preferred a solution based on write-once or write-protectable media, with a physical write-protect switch somewhere (this is technologically trivial), to a solution that literally gives the keys to booting Linux to parties that are potentially hostile to the use of Linux.

You may assume that MS will never require SecureBoot in PCs (as is the case for UEFI ARM) in future, however I (and perhaps others) are not comfortable with that assumption. I'm allowed that.

Practical security for 2014

Posted Jan 16, 2014 18:01 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (25 responses)

"I don't have a map of NVRAM handy to tell for sure"

You could perform some minimal quantity of research and then you would be able to tell for sure?

"but if there's a sufficient gap between the BIOS setup variables and the area the OS still must write to, then it would be electrically quite feasible to pull up or down relevant address lines according to a jumper to prevent that BIOS config data being written to"

No, because the address and data lines are multiplexed and so you're (a) preventing *reading* from the protected addresses as well, and (b) you're corrupting data in the registers that you can access. Really. Please look at the data sheet, and then remember that you're still talking about hardware that hasn't shipped within the past 15 years because now it's all in the chipset and it's really awkward to try to tie jumpers to internal address lines on chips fabbed at 45nm.

You're right that the software I'm describing does not currently exist, but nor does the hardware you're describing. I can implement my solution and deploy it to millions of existing machines, thereby improving security over the status quo. You can't. And yes, you're right that it's possible that Secure Boot could be used to remove user freedom. But saying "The security benefits provided by Secure Boot do not outweigh the threat to user freedom" is an entirely different argument to "Secure Boot provides no security benefits". One is a matter of opinion based on your weighting of various threats. The other is simply wrong.

Practical security for 2014

Posted Jan 16, 2014 18:18 UTC (Thu) by paulj (subscriber, #341) [Link] (24 responses)

That isn't what I said.

I said SecureBoot provides no security benefits above boot from RO media, or boot from known-"good" media.

Where SecureBoot differs from that is in providing /selective/-write media, which has some practical benefits when it comes to distributing and installing without user-intervention, I'll agree (if indeed you make that network "phone home" stage work without fuss).

I don't think I'm wrong in that characterisation.

As for removing user freedom, SecureBoot *actively* does so by default. It does not trust the end-user by default, but only a select few entities. That's what the *selective* part inherently is all about. Most PCs have a way for now to allow a user to enroll their keys, but not all do - as nix commented. Whether this ability to enroll end-user keys and/or bypass SecureBoot will remain, we will see. However, undoubtedly, MS now have much greater control over what PCs will boot, and this wouldn't have been the case with a local-only, user-controlled solution.

We clearly disagree on assumptions about how the future will pan out, but I don't think the above is wrong.

Practical security for 2014

Posted Jan 16, 2014 18:25 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (23 responses)

"I said SecureBoot provides no security benefits above boot from RO media"

True, in the universe where you can ensure that you only boot from RO media. Which isn't this one. As a result, Secure Boot provides security benefits.

"Most PCs have a way for now to allow a user to enroll their keys, but not all do - as nix commented."

I have never seen a system that provides no mechanism for this[1] and I've seen no credible reports of them existing. If anyone believes otherwise, I'm happy to buy myself any hardware they claim lacks this functionality as long as they're willing to pay for it if it turns out they're wrong.

[1] The exception is some desktop boards produced between Secure Boot being specified and Microsoft's requirements for key management being published, but none of those boards enable Secure Boot by default so it's not an interesting case - you can just pretend that they don't implement it at all.

Practical security for 2014

Posted Jan 16, 2014 18:52 UTC (Thu) by paulj (subscriber, #341) [Link] (16 responses)

Sorry, no. If we're restricted to the here and now, where RO-only media is subject to a boot-order attack, then SecureBoot as deployed today is also subject to re-subversion. That's precisely why you introduced that network boot-loader verify stage.

If the SecureBoot scenario can rely on not-implemented technology, then the RO-only media case also may do so¹.

Can you, using current technology, implement and roll out your network boot solution one day, I agree, probably yes. Will it provide the claimed security (assuming a reliable network)? Perhaps, that depends on the details, which remain to be seen. Have you fleshed them out in further detail anywhere, outside of this LWN comment thread?

As for the system that doesn't allow enrollment of user-keys, sorry, I misrepresented nix's problem. He just couldn't get SecureBoot to work with a distro, but it's not actually clear if he could have enrolled his own keys or not. It seems he chose not to bother with that because of the complexity of SecureBooting self-signed materials. However, I thought some vendor had a problem at some stage with their UEFI missing end-user enrollment functionality (was it Asus?). The exact size of the set of UEFI implementations with that problem is far from the main point though.

1. Or, old technology, with a little bit of active logic in front of the RTC chip to hold the write RTC lines down if the previous address cycle tried to access the upper-half of the RTC. Arguing about the exact minutiae of that isn't hugely helpful, except as some kind of cock-on-desk-slapping exercise. The point is, if a vendor of that logic wanted to provide a hardware switch WP functionality today, e.g. cause industry wanted it for security, it'd be trivial to add.

Practical security for 2014

Posted Jan 16, 2014 18:55 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (14 responses)

Again, Existing hardware Secure Boot provides all the infrastructure required to implement this functionality. Existing hardware does not provide the infrastructure required to implement secure boot from read-only media. If you can't see the difference between these two situations then there's really no point discussing it.

Practical security for 2014

Posted Jan 16, 2014 19:06 UTC (Thu) by paulj (subscriber, #341) [Link]

I don't disagree with you on that.

However, the full security implications of your proposal will not be clear until it is actually implemented and used. Will it achieve the security goals you set for it? Possibly, but it's far from clear until fully realised and tested. I don't think any reasonable person could disagree with that.

Practical security for 2014

Posted Jan 17, 2014 16:48 UTC (Fri) by nix (subscriber, #2304) [Link] (12 responses)

Existing hardware does not provide the infrastructure required to implement secure boot from read-only media.
Thus neatly explaining why the livecd of the distro I tried to install in the post above UEFI-booted without a secure boot error, unlike everything UEFI-booted off the hard drive. Another irregularity exposed to end users but not documented anywhere they can see (not until this post of Matthew's, anyway).

Practical security for 2014

Posted Jan 17, 2014 17:01 UTC (Fri) by mjg59 (subscriber, #23239) [Link] (11 responses)

Er. I think you've misunderstood what I said there. Secure Boot works fine from read-only media, but existing hardware provides no way for you to implement equivalent security using read-only media and no UEFI Secure Boot.

Practical security for 2014

Posted Jan 18, 2014 20:43 UTC (Sat) by nix (subscriber, #2304) [Link] (10 responses)

Ah. I did misunderstand. You're right that you can't ensure that your BIOS hasn't been reflashed by hostile parties without something like secure boot, but I'm somewhat unclear how secure boot can fix that, given that it's the BIOS that *implements* secure boot in the first place... surely a hostile BIOS can claim to be doing signature verification, and then, well, just not do it?

Practical security for 2014

Posted Jan 18, 2014 21:24 UTC (Sat) by paulj (subscriber, #341) [Link] (2 responses)

Many PC boards had electrically secure write-protect jumpers in EEPROM days. That's pretty damn secure. Indeed, I might have more faith in that than software signature schemes, depending on the scenario.

Practical security for 2014

Posted Jan 18, 2014 21:48 UTC (Sat) by paulj (subscriber, #341) [Link] (1 responses)

Oh, and how is UEFI firmware in flash is protected for updates? The trust anchor in SecureBoot is established by the firmware, right (not in the CPU)?

Practical security for 2014

Posted Jan 18, 2014 22:05 UTC (Sat) by mjg59 (subscriber, #23239) [Link]

The firmware verifies the update before flashing it. The SPI controller prevents the OS from writing to the flash.

Practical security for 2014

Posted Jan 18, 2014 21:39 UTC (Sat) by raven667 (subscriber, #5198) [Link] (1 responses)

Yes, absolutely, if someone intercepts your hardware and flashes a bogus UEFI that pretends, they could even add keys to SecureBoot to trust their bogus bootloader but that requires physical access and can't be done remotely by malware because the UEFI firmware will check the signature of any updates before applying them, a core feature of SecureBoot.

Practical security for 2014

Posted Jan 18, 2014 21:50 UTC (Sat) by paulj (subscriber, #341) [Link]

You're assuming the UEFI firmware, the reference implementation for which contains a fair amount of non-trivial C code, is free of exploitable defects.

Practical security for 2014

Posted Jan 18, 2014 22:02 UTC (Sat) by mjg59 (subscriber, #23239) [Link] (4 responses)

It has nothing to do with modifying the BIOS. You can install a known good kernel on piece of read-only media and use that to boot the OS installed on your hard drive. I, as an attacker, can install an evil kernel and bootloader on your hard drive and then rewrite the CMOS settings to instruct your system to boot from the hard drive instead of the read-only media. The BIOS is entirely intact, it's just doing what it was told to do.

Practical security for 2014

Posted Jan 18, 2014 22:06 UTC (Sat) by paulj (subscriber, #341) [Link] (3 responses)

BTW, I've been trying to find which PC BIOS standard/convention required the BIOS boot-order config be in a known location in the NVRAM. Do you know where I can find that?

Practical security for 2014

Posted Jan 18, 2014 23:01 UTC (Sat) by mjg59 (subscriber, #23239) [Link] (2 responses)

It's not in a fixed location, but there's a small number of firmware vendors and they tend to leave things in the same place over product releases. You can pull the firmware vendor out of DMI so it's trivial to automate it.

Practical security for 2014

Posted Jan 18, 2014 23:18 UTC (Sat) by paulj (subscriber, #341) [Link] (1 responses)

Yeah. Digging more, it seems the RTC and some of the slots immediately after it are "well-known", and the rest vary with BIOS vendor (and even the revision of BIOS). This seems one of the more comprehensive summaries:

http://oopweb.com/Assembly/Documents/InterList/Volume/CMO...

I've been trying to work out what the other half was for, the SRAM, and as far as I can work it seems that was used for ESCD and ISA PNPBIOS stuff.

Practical security for 2014

Posted Jan 18, 2014 23:19 UTC (Sat) by paulj (subscriber, #341) [Link]

err, s/ISA//.

Practical security for 2014

Posted Jan 17, 2014 16:46 UTC (Fri) by nix (subscriber, #2304) [Link]

FWIW, the year-and-a-half-old asus motherboard on the Ivy Bridge desktop I'm using right now has secure boot and no end-user key enrollment. However, it does have secure boot off by default (as Matthew said would be true for a desktop made in that time period), and it's easy to turn UEFI off too. So I have no real complaints on that score.

Practical security for 2014

Posted Jan 17, 2014 16:44 UTC (Fri) by nix (subscriber, #2304) [Link] (5 responses)

I have never seen a system that provides no mechanism for this[1] and I've seen no credible reports of them existing. If anyone believes otherwise, I'm happy to buy myself any hardware they claim lacks this functionality as long as they're willing to pay for it if it turns out they're wrong.

[1] The exception is some desktop boards produced between Secure Boot being specified and Microsoft's requirements for key management being published, but none of those boards enable Secure Boot by default so it's not an interesting case - you can just pretend that they don't implement it at all.

Well, yes. Every PC I have set up in the last two years (all three of them, I don't do this unless I must!) has had no way to enroll new keys that I could find, but has allowed you to boot in non-UEFI mode, if you could figure out how to do it past the appalling mistranslated English of the BIOS interface.

It is quite possible that the most recent one, probably made in the last six months (I set it up in November) did have a way to enroll keys, but I just couldn't find it because the BIOS setup translations were so bad. It had an option labelled "UEFI uefi enable" with the extra help description "enabling to enabling UEFI". It was off by default: to switch to BIOS booting, I had to turn it on. There was a secure boot option, which was on by default and was greyed-out so I couldn't turn it off, and what may have been a key enrollment facility which I couldn't figure out how to use because they hadn't bothered to translate it at all and it hit me with what I guess was Taiwanese! Unfortunately I didn't think to note down the vendor of this glorious piece of misdesign, I was too busy cursing it and trying to get my friend's brand new machine to boot at all.

Even once I'd taught the BIOS to boot without using the secure-boot-apparently-mandatory UEFI, I had to separately convince the Linux distro's setup program to write a BIOS bootloader rather than the UEFI bootloader it was insisting on writing out, which the BIOS then silently didn't use because it wasn't booting in UEFI mode except when booting off the distro's live CD: I note that when UEFI-booting off the CD it was apparently not using Secure Boot, but it didn't want to do that while UEFI-booting off the hard drive! (Of course, nothing anywhere in the Mint installer tells you which mode you've booted in or what sort of bootloader has just been written out, so it took me literally hours to figure out why my attempts to boot were still failing despite the distro having been allegedly installed. Maybe something in /sys tells you, I dunno. It is hardly made obvious anywhere. I suppose in the final-state world in which everyone uses UEFI and it works properly and doesn't get in your way, such an option would be pure noise. It very much isn't right now.)

This brave new world is not better than the old, unless you think this sort of downright stupid palaver is pleasant and expected when setting up new systems. Setting them up was very much easier three years ago than it is now. It's not secure boot itself getting in the way so much as really badly written and translated, pathologically unhelpful UEFI BIOSes, but would you trust the people who wrote that stuff to do anything security-related right? I wouldn't trust them to write 'hello world'.

Practical security for 2014

Posted Jan 17, 2014 16:58 UTC (Fri) by mjg59 (subscriber, #23239) [Link] (2 responses)

Boards made more than a year ago are unlikely to implement Secure Boot at all, and certainly won't enable it by default - you wouldn't be able to install Windows 7 otherwise.

"I had to separately convince the Linux distro's setup program to write a BIOS bootloader rather than the UEFI bootloader"

Which distribution? The kernel won't provide UEFI functionality unless it's passed a pointer to the UEFI tables by the bootloader, and the only way that can happen is if you booted via UEFI. If there's a distribution that installs a UEFI bootloader even though it can't write to the UEFI boot variables, that's a criminally incompetent implementation and certainly a distribution bug. Or, alternatively, you're wrong when you claim that you booted via BIOS compatibility.

"It's not secure boot itself getting in the way so much as really badly written and translated, pathologically unhelpful UEFI BIOSes"

…and so entirely irrelevant to the discussion that we're actually having here?

Practical security for 2014

Posted Jan 17, 2014 17:13 UTC (Fri) by raven667 (subscriber, #5198) [Link] (1 responses)

It sounded like the sequence of events was that he successfully installed a GPT partition and UEFI boot loader but then was unable to boot into it due to some UEFI problem, he then tried to re-install after reconfiguring the UEFI to boot in BIOS mode but the installer detected that he had a GPT partition and failed to install a BIOS compatible boot loader without some convincing and probably wiping the install and partition table.

Practical security for 2014

Posted Jan 18, 2014 20:38 UTC (Sat) by nix (subscriber, #2304) [Link]

Yes. (Actually the GPT partition was already there: the machine had a UEFI-booting Windows on it.)

Practical security for 2014

Posted Jan 17, 2014 17:03 UTC (Fri) by raven667 (subscriber, #5198) [Link] (1 responses)

That sounds truly awful and that is not what I expect to be the norm. I figure the best effort is spent on making the reference design really work well and licensing it liberally, these small vendors aren't going to invest in writing their own if they can easily pick up one cheaply or for free. They differentiate in their awful UIs and not in the underlying components which actually do the work.

Practical security for 2014

Posted Jan 18, 2014 20:41 UTC (Sat) by nix (subscriber, #2304) [Link]

Agreed. However, if the UI is so bad that nobody can figure out how to use it unless they read zh_TW, I'm not sure it matters how good the underlying code is (except that it might be less likely to fail completely).

Practical security for 2014

Posted Jan 16, 2014 15:30 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (6 responses)

No, UEFI doesn't make that immutable. So, sure, change the boot path. And now the machine won't boot because the backdoored bootloader you asked it to boot isn't signed.

Practical security for 2014

Posted Jan 16, 2014 15:57 UTC (Thu) by paulj (subscriber, #341) [Link] (5 responses)

Mat, like the other commentator, I have great respect for your work. I regularly thank you when my machines boot, suspend and/or resume correctly, due to your part in hammering out the bugs in often infuriating BIOS, ACPI, etc., code. However, I have to wonder if you've become somehow emotionally invested in the goodness of SecureBoot in a way that is affecting your ability to think critically through the security issues involved. At least, you seem to have different standards for system security when SecureBoot is involved, compared to when it is not.

The context is there is some bug that allows exploits to run in early boot (e.g. some terrible kernel filesystem bug), affecting the installed system. A known-fixed/good system needs to be booted to reliably allow the installed system to be updated and the exploit closed off, without fear of it being subverted too.

*You* yourself earlier raised the issue of firmware boot-order and writeability by the running system being a security issue, because it would mean the existing running system (which ergo must have booted fine) could re-direct any reboot away from known-fixed/good media and back to known-subvertable (e.g. the currently booted system). This was in the context of non-SecureBoot, booting from, say, CDROM.

For SecureBoot you say the system could still (automatically) boot some simple bootloader (which'd avoid looking at any local mutable state, as much as possible), and so could download the known-fixed kernel and boot into a known-fixed system capable of the reliable update. The boot-order problem surely applies *equally* to the SecureBoot case. The subverted, installed system could otherwise change the boot-order and boot the installed, persistently subvertable, system directly.

You can't claim that boot-order rewriting is a problem for the "boot from CDROM/other-RO-media", non-SecureBoot case, while claiming it isn't a problem for the SecureBoot case. Surely?

Also, I don't know if SecureBoot has a revocation system for kernel signatures. If it doesn't, any subversion could always install an old, persistently-subvertable, signed kernel - even if the current kernel is *not* persistently subvertable. If it's the case that SecureBoot doesn't do revocation, then SecureBoot would in fact be *worse* than a true RO-boot in terms of practical security goals.

Practical security for 2014

Posted Jan 16, 2014 16:02 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (4 responses)

"You can't claim that boot-order rewriting is a problem for the "boot from CDROM/other-RO-media", non-SecureBoot case, while claiming it isn't a problem for the SecureBoot case. Surely?"

Of course I can.

"The subverted, installed system could otherwise change the boot-order and boot the installed, persistently subvertable, system directly."

How? The second stage bootloader isn't trusted by the firmware. You need the first stage bootloader to bridge between the two.

"I don't know if SecureBoot has a revocation system for kernel signatures."

It does. Perhaps you should spend some time learning something about the topic before making claims about its security?

Practical security for 2014

Posted Jan 16, 2014 16:11 UTC (Thu) by paulj (subscriber, #341) [Link] (3 responses)

This second stage network bootloader you talk about doesn't exist. The first stage bootloader very likely will have to be capable of directly booting the installed system, at least for a transition period, while this 2nd stage bootloader is being deployed. Possibly, practical details may require that capability to exist for a long time more.

If the boot order - in firmware or the config of this 1st stage bootloader - can be made to boot the existing system, you've lost. You've pointed that out yourself for the non-SecureBoot case.

If SecureBoot does have revocation then that point doesn't matter. It doesn't affect the other points.

Practical security for 2014

Posted Jan 16, 2014 16:24 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (2 responses)

What second stage network bootloader? This would be implemented in the first stage.

"The first stage bootloader very likely will have to be capable of directly booting the installed system, at least for a transition period, while this 2nd stage bootloader is being deployed."

And once it's implemented, the rest of the stack is signed with a key that the old first stage bootloader doesn't trust.

Practical security for 2014

Posted Jan 16, 2014 16:43 UTC (Thu) by paulj (subscriber, #341) [Link] (1 responses)

Well, you mentioned a second-stage bootloader first I think:

"How? The second stage bootloader isn't trusted by the firmware. You need the first stage bootloader to bridge between the two."

I don't know how this network SecureBoot network verifier is meant to work in detail as I've only ever read about it in the comments to this article. Please feel free to point me to detailed designed docs. In my head we've got. At present:

firmware -> Bootloader -> local Linux

And AFAICT you're proposing this must become one of these 2 possibilities:

1. firmware -> Bootloader -> secure-check/update via Internet bootloader -> local Linux

2. firmware -> Bootloader with secure-check/update via Internet functionality -> local Linux

The number of stages is mostly irrelevant. That secure-check/update stage could be in a separate bootloader stage, or a stage within the 1st bootloader - it doesn't matter to what we're discussing, AFAICS. The important thing to me is whether the configurable bootloader will be able to be configured to boot the local Linux system.

I'm not convinced distros would easily be able to remove the ability to directly boot the installed system - without doing the secure-check/update part - any time soon. Indeed, just the thought that SecureBoot ultimately is going to *require* a special "phone home" network stage, and that it would refuse to boot my local system otherwise is making me a bit queasy.

Practical security for 2014

Posted Jan 16, 2014 16:47 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

"The important thing to me is whether the configurable bootloader will be able to be configured to boot the local Linux system."

And the answer is, obviously, "only if you have physical exercise to the machine", because the alternative would defeat the entire point of the exercise.

Practical security for 2014

Posted Jan 16, 2014 15:10 UTC (Thu) by paulj (subscriber, #341) [Link] (11 responses)

If kexec is a security issue, then the kernel itself is a security issue. If the attacker has root, they can modify the running kernel and modify it to add kexec-like functionality, they don't need it to contain kexec to begin with. Removing kexec from the kernel only protects from the type of people who are *not* in the business of exploiting kernels.

Practical security for 2014

Posted Jan 16, 2014 15:34 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (10 responses)

How does root modify the running kernel?

Practical security for 2014

Posted Jan 16, 2014 16:04 UTC (Thu) by paulj (subscriber, #341) [Link] (9 responses)

Traditionally there were interfaces to map all/good chunks of kernel memory and twiddle it. If those have been removed (and it seems the obvious one I was thinking of has been), then the attacker uses an exploit to inject code. Specific cases of the latter get published quite regularly (as I'm sure you know as a regular LWN reader), and no doubt there are many more unpublished.

Practical security for 2014

Posted Jan 16, 2014 16:06 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (8 responses)

"the attacker uses an exploit to inject code"

Ok. So because the kernel has bugs, we shouldn't remove features that are equivalent to the bugs? Inverting the argument, because the kernel has kexec, we shouldn't fix any local kernel exploits that require root?

Practical security for 2014

Posted Jan 16, 2014 16:26 UTC (Thu) by paulj (subscriber, #341) [Link] (7 responses)

We should fix specific instances of such bugs, yes. Even if they make little security difference, they will have correctness issues.

After this, we depart. I simply do not believe it is possible for the Linux kernel to be free of this class of bugs. I do not believe this class is bounded over time (not infrequently the code is quite old, when exploitable bugs are found).

I do not believe it makes logical sense to remove a *useful* feature for a security justification that is utterly unachievable, given I do not think that class of bugs will ever be tamed in size in any way.

You, I gather, believe that class of bugs can be minimised sufficiently to (presumably) a point that at any instant in time, there is a low probability that any given attacker will have knowledge of one. I think this belief is incredibly, incredibly optimistic, given experience, and others here have said so too.

Your position is logical, as is mine (I think). The difference is that assumption, AFAICT.

Practical security for 2014

Posted Jan 16, 2014 16:30 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (1 responses)

So why was STRICT_DEVMEM implemented? Why do we support signed modules? Why do most distributions ship without /dev/kmem support? Because we have rejected the idea that root should be able to modify the running kernel. Bugs that permit that are fixed. Interfaces that permit it are rejected or flagged with huge warning labels. kexec is, in this respect, a historical anachronism. If someone proposed it now, I doubt it would be accepted in its current form.

Practical security for 2014

Posted Jan 16, 2014 16:50 UTC (Thu) by paulj (subscriber, #341) [Link]

Well, others share your assumption, clearly. However, there is no point in the history of the kernel to date where that assumption has been borne out, between that date and now. Historical evidence does not say that assumption is justified. Yet, that some continue to act as if that assumption is valid is also true, as you point out.

Practical security for 2014

Posted Jan 16, 2014 20:07 UTC (Thu) by raven667 (subscriber, #5198) [Link] (4 responses)

> After this, we depart. I simply do not believe it is possible for the Linux kernel to be free of this class of bugs.

Woah, there is not some boolean secure/insecure which depends on the non-existance of exploitable kernel bugs, that's clearly ludicrous and I don't think anyone is arguing that point except for you. It is almost as if you believe there is some "secure" technology out there, if only we didn't use C.

If your fundamental assumption and position is that because code execution vulnerabilities can exist in software that security technologies are pointless then you are not going to find common ground to meet on so further discussion is probably pointless.

If you think there is a sliding scale of risk depending on whether a particular bug is known, how well known it is, whether it is fixed and whether it is being used in automated malware (like spambots) then maybe there is some point.

I'm just not sure you are being clear about your underlying assumptions so attempts to discuss the technical pros/cons of this technology are running into severe communication problems which is making this thread far larger than it really needs to be to cover this ground.

Practical security for 2014

Posted Jan 16, 2014 22:08 UTC (Thu) by paulj (subscriber, #341) [Link] (3 responses)

No, I don't believe there is "secure" technology out there at the moment. In a much earlier comment I said we need a lot more research on how to build secure systems. Possibly there's room for more hardware-checked abstractions, as I think helloworld pointed out earlier, which I'd agree with. Certainly, I think we need more to build more tools, e.g. parser generators / serialisers for low-level binary streams (file formats, network protocols, etc), to at least automate some of the tedious, syntactic stuff.

I completely agree with you there's a sliding scale of risk.

I just don't believe there's any prospect for the Linux kernel and/or early-boot code, to ever be sufficiently "free" of bugs, where that means that at any point of time, the probability that any competent hacker will know of or be able to find within O(days / low # of weeks) an exploitable bug will be sufficiently below 1 to be of value¹. I just don't think there's any prospect of this happening without radical changes in how this code gets developed - my sense of security history strongly strongly suggests.

I'm not saying don't fix the bugs when they're found. However, I don't see the point in removing the *useful* functionality and flexibility (inc ease of install), and *adding* significant complexity, in order to gain the assurance that the code *was* the code we intended to run, when the problem is how easy that code is to subvert at runtime.

The weak link is that we're writing software using practices known to give rise to *high* numbers of defects. We don't know how to write 0 defect code, but there are known ways to reduce the defect rate. I think those would be far more effective than SecureBoot, and they needn't cost flexibility.

Going back to the sliding scale of risk - Secure Boot just doesn't do much to budge it. The problem is the practice of software engineering, which SecureBoot does nothing for. The exploitable system remains so, despite SecureBoot (and potentially persistently so even to fixed exploits, until this network boot check thing is rolled out, and even then nothing can be done about the unknown, unfixed exploits - not in scope for SecureBoot).

Now, mjg59 and I guess you have a different view on how achievable that probabilistic "free" of bugs condition is. I accept that you, mjg59 and others take a more optimistic view. However, I and yet others do not believe history justifies that optimism. On my assumption, I think SecureBoot gives you the knowledge that you booted the right buggy and easily compromised software, while taking useful functionality away,m and adding complexity with further bugs. I don't think that trade-off is worth much to me.

I am though more optimistic about the scope for improving security through better engineering of the software, perhaps with some hardware assistance. I think there's room there to make a significant impact on security over the next decade or two. Further, work in that area does *NOT* have to require giving the keys to what users may boot to large corporations, which makes it more valuable again to me.

I'm trying to be fairly clear about separating out my assumptions from my logic. It's fairly clear to me that where the likes of mjg59 and yourself and I disagree is on the assumptions about rates of exploitable defects, and on the relative value of flexibility and end-user freedom. I think I understand your positions, I just disagree. It's just that a shame that, apparently, I'm not able to communicate my side clearly enough to make you feel the same way (i.e. understand but disagree). ;)

1. Exactly how far that'd have to be is debatable, and we've no way to measure this AFAIK, so let's not go there. ;) We do know that I think it will never be usefully below 1, while you, mjg59, etc., think it will be.

Practical security for 2014

Posted Jan 17, 2014 16:45 UTC (Fri) by raven667 (subscriber, #5198) [Link] (2 responses)

> taking useful functionality away,m and adding complexity with further bugs. I don't think that trade-off is worth much to me.

I disagree on this point, I don't see how functionality is being taken away when you have control of the keys and whether the feature is enabled at all.

I also don't see how adding some basic signature or hash value checks, something that we do in plenty of other security sensitive software like OpenSSL or OpenSSH or GPG or NSS, is adding a significant amount of complexity to actually be a negative.

> I am though more optimistic about the scope for improving security through better engineering of the software, perhaps with some hardware assistance. I think there's room there to make a significant impact on security over the next decade or two.

You are _way_ more optimistic on that front than I think any of us are, which is why are are more interested in simple integrity checking technologies that deal with running in an imperfect universe than pinning our hopes on complex software being any more secure in the future. You keep accusing us of optimism and presuming the kernel is unexploitable but it would seem that this is in fact _your_ assumption and not ours.

You can probably make a small body of software tough, but not impossible, to exploit, the integrity checking in uEFI and the bootloader is not a ton of code. Getting that small bit of code to be tough is far more practical than expecting software engineering to make the entire stack impossible to exploit.

Practical security for 2014

Posted Jan 17, 2014 17:09 UTC (Fri) by paulj (subscriber, #341) [Link] (1 responses)

Features being removed: Kexec. Also, I'm somewhat worried about hypervisor functionality beyond the mid-term, based on the precedent of kexec.

Re optimism. I'm not assuming an unexploitable kernel at all. Indeed, I've been clear that I'm very much of the opinion that the current scheme of things is close to unsalvageable. :) I do think it is possible to build much more secure systems, even if they still run on a kernel with many defects, but I thought I made it clear I think it will take *decades* of research and re-engineering to get there. :) Oh, and I forgot, also a fairly significant shift in priorities in industry, that puts security a lot higher than it does now.

I'm optimistic on what is *possible* for the long-term. However, utterly pessimistic about what we have now, and I continue to think it's mostly pointless to know you started from the right state, when the problems lie in the states there-after (and history predicts that won't change, for the current systems and how they're engineered).

Practical security for 2014

Posted Jan 17, 2014 17:11 UTC (Fri) by mjg59 (subscriber, #23239) [Link]

Features removed: kexec until a secure implementation is added, which is a work in progress. Since kexec allows you to trivially circumvent Secure Boot, there's no point in using Secure Boot if you want kexec. So just disable Secure Boot and kexec miraculously reappears.

Practical security for 2014

Posted Jan 14, 2014 18:18 UTC (Tue) by njwhite (subscriber, #51848) [Link]

> Unfortunately for us PC firmware authors are terrible at writing software. The fact that UEFI is FUCKING HUGE and extremely complex is not helping any. Combine that with the fact that it's closed source and then it's pretty much a nightmare. There is no bottom you can trust.

The verifying uboot system Google developed for its Chromebooks looks like a sensible alternative to me, which they run after loading coreboot (at least for x86). That stuff is sensibly coded, reasonably small, and all free software. I haven't looked very closely, so I may be missing something, but that's how it looks to me.

Practical security for 2014

Posted Jan 11, 2014 0:03 UTC (Sat) by lsl (subscriber, #86508) [Link] (4 responses)

> Not exploit, but *persistent* exploit - i.e. one that persists after a reboot. The way this LWN article is reporting what mjg59 has said suggests that mjg59 may be claiming that SecureBoot prevents an exploit from persisting across a reboot:

I don't read it as persisting across reboots but as persisting across *reinstalls* of the operating system. Modifying the firmware in a way that compromises even a newly installed kernel is indeed made harder by SecureBoot-like techniques.

Practical security for 2014

Posted Jan 11, 2014 0:47 UTC (Sat) by PaXTeam (guest, #24616) [Link] (3 responses)

why would a reinstalled OS be any more resistant to the exploit technique(s) that its previous incarnation was?

Practical security for 2014

Posted Jan 11, 2014 16:12 UTC (Sat) by Karellen (subscriber, #67644) [Link] (2 responses)

Because exploits get patched over time?

Practical security for 2014

Posted Jan 11, 2014 17:25 UTC (Sat) by paulj (subscriber, #341) [Link]

And new bugs get added all the time, both with feature additions and even the bug fixes. There is no reason to think that OS system software is even converging on security-bug-free over time - perhaps the opposite.

Practical security for 2014

Posted Jan 11, 2014 18:09 UTC (Sat) by PaXTeam (guest, #24616) [Link]

exploits don't get patched (or at least it's not your concern unless you're an attacker), exploitable bugs do however. and it's the same fixes that get installed on a system that's kept up-to-date, so where's the benefit of reinstallation? you get the same code with the same fixes (actually, less with a fresh installation since said fixes have to be downloaded first and i'm sure everyone heard the stories of how vulnerable boxes get infected before they can be patched that way).


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds