Other long term problems
Other long term problems
Posted Jun 6, 2012 8:52 UTC (Wed) by dgm (subscriber, #49227)In reply to: Other long term problems by drag
Parent article: Fedora, secure boot, and an insecure future
Posted Jun 6, 2012 18:59 UTC (Wed)
by pjones (subscriber, #31722)
[Link] (17 responses)
Posted Jun 6, 2012 23:10 UTC (Wed)
by rahvin (guest, #16953)
[Link] (16 responses)
This is exactly the problem, people are suggesting that the way to secure their system is to give the BIOS guys the keys to their computers. I'd argue that the BIOS providers are the LAST company on earth we want to be responsible for securing the computer. Maybe if CoreBOOT was standard and Phoenix, Award and all the other culprits were gone it might be an option but these are not companies with a either a track record of reliable updates let alone security and we're talking about giving them the keys to the entire system. It's scary, and what's scarier is that people think it's a good idea.
Posted Jun 7, 2012 2:14 UTC (Thu)
by pjones (subscriber, #31722)
[Link] (15 responses)
No, that's not the case. It has to be quite a bit craftier than just that. The spec requires that most code runs in a mode of operation in which the flash which houses the keys has write enable physically disabled.
Posted Jun 7, 2012 10:27 UTC (Thu)
by etienne (guest, #25256)
[Link] (2 responses)
That is the problem, if it is physically disabled (by a bit which cannot be reseted without complete power-down) nobody can update the key to revoke anything.
Posted Jun 14, 2012 14:09 UTC (Thu)
by JanC_ (guest, #34940)
[Link] (1 responses)
Posted Jun 14, 2012 15:45 UTC (Thu)
by etienne (guest, #25256)
[Link]
Posted Jun 7, 2012 10:37 UTC (Thu)
by nelljerram (subscriber, #12005)
[Link] (11 responses)
No, that's not the case. It has to be quite a bit craftier than just that.
Huh? The OP simply said "malware ... can ..."; they didn't say anything about how "crafty" it needed to be to do that. How does your response relate to what the OP said?
The spec requires that most code runs in a mode of operation in which the flash which houses the keys has write enable physically disabled.
Again, how does that relate? By saying "most" you are allowing that some code runs without key-writing disabled - and clearly this must the case, or else it would be impossible ever to update the keys!
So your post does not refute the previous one, or illuminate it. If anything it corroborates it, but strangely using language that sounds like a refutation.
Posted Jun 7, 2012 16:16 UTC (Thu)
by raven667 (subscriber, #5198)
[Link] (10 responses)
Posted Jun 8, 2012 1:00 UTC (Fri)
by pretter (guest, #84918)
[Link] (9 responses)
http://fedoraproject.org/wiki/User:Pjones and http://fedoraproject.org/wiki/User:Pjones/Features/Secure... would be a good start.
Posted Jun 8, 2012 8:49 UTC (Fri)
by nelljerram (subscriber, #12005)
[Link] (8 responses)
This whole thing smells really bad to me. At least two standard ploys have been used here that are usually more associated with politics (in the bad sense of that word).
1. Deploying extra people, previously not well known in the LWN forum, to defend a position by the preponderance of their comments.
2. Saying that we don't need to worry because it's only a proposal at this stage, and nothing is set in stone. (Obviously (1) it is a done deal already, or else all the RH people would be more open in their responses, and (2) when the initial attention and discussion has died down, the proposal will be set in stone.)
Secondly there's the ethical point, that RH have chosen overall to give aid to a Microsoft-inspired and Microsoft-favouring system, and to make themselves hostage to that, instead of unequivocally fighting against that.
Finally there are technical details that just don't seem to make sense, and where the "answers" given in these comments are inadequate and far below LWN's usual level of technical communication.
All in all, I'm afraid it's difficult for me to believe that there isn't an ulterior motive.
Posted Jun 8, 2012 16:30 UTC (Fri)
by raven667 (subscriber, #5198)
[Link]
You make it sound like treason, which is a ridiculous concept when applied to this case. Working with standards that MS also works with and has influence over is not an "ethical" challenge. Fedora and mjg59 have already stated their constraints, they are willing to work on secure boot on systems where key management is available to the end user (even if it isn't as user-friendly as they would like) and are not working on secure boot for systems which are boot locked, without key management (Win8 ARM).
> All in all, I'm afraid it's difficult for me to believe that there isn't an ulterior motive.
This isn't a matter of faith, it's a matter of reading the very open dialog that exists. The fact that you see ulterior motives probably reveals more about your own thought process than illuminates the discussion.
Posted Jun 11, 2012 11:51 UTC (Mon)
by nix (subscriber, #2304)
[Link] (6 responses)
By extension, unless holes in the ID are being filled in, pjones has been reading LWN for a while.
I'm concerned about this problem too. As I see it there are two possibilities. Either updating keys and adding revocations is prohibited except in a special mode, in which case malware authors will copy whatever that mode is (if necessary by having kernel-mode code loiter and spy on an update in progress to observe variable parameters, before elevating themselves from kernel-mode to BIOS compromise), or updating keys is prohibited but adding revocations is not, in which case malware authors have an instant free DoS attack vector.
It is possible that, given a completely compromise-free kernel, malware could never run in kernel mode to spy on a key update -- but firstly a compromise-free kernel is a pipe-dream and secondly malware that couldn't even get to kernel mode could never compromise the BIOS in the first place.
So as far as I can see, as long as key updates or revocations are possible under software control at all this whole thing adds no security, adds a lot of inconvenience, and allows MS to prohibit other OSes from running on their ARM devices. (Which is the real point of all this.)
Now perhaps key updates and revocations cannot be scripted, and can only be triggered from the BIOS (which means Windows updates cannot provide revocations for insecure keys but can only ask the user to do it). Desktop PCs might be safe, but server-class PCs are not, because they generally allow remote access to their BIOSes using technologies like IPMI. So on such a network malware on *another* machine can watch for a server to start rebooting, add its own key pre-emptively, then later infect it and replace its firmware. In general non-scriptable updates hugely annoy IT staff in large organizations anyway because they mean some poor sap has to walk around physically from desk to desk. So I bet the thing ends up scriptable across all machines, which eliminates its security advantages.
Non-scriptable updates would mean that no keys ever got revoked on most desktop devices. So either this thing adds security only until the first key revocation (non-scriptable case) or it adds security only until the bad guys learn how to use a debugger, i.e. not at all (scriptable case).
So I guess I still can't see the point of all this.
Posted Jun 11, 2012 12:21 UTC (Mon)
by nelljerram (subscriber, #12005)
[Link]
True, but I thought I saw, a few (or several, now) days ago, "pjones (guest)".
But I could be wrong about that, and in any case it's a somewhat distasteful point to make, so please consider that withdrawn.
Regarding everything else you wrote: I agree, and thanks for expounding it so clearly.
Posted Jun 11, 2012 19:13 UTC (Mon)
by raven667 (subscriber, #5198)
[Link] (1 responses)
> Now perhaps key updates and revocation ...
> So I guess I still can't see the point of all this.
This is an actual written standard with actual implementations, your assumptions are questions and those questions have answers. Instead of spilling a lot of ink with possibles and maybes it would be worthwhile to see how this stuff actually works.
Posted Jun 11, 2012 22:03 UTC (Mon)
by nix (subscriber, #2304)
[Link]
Posted Jun 11, 2012 23:12 UTC (Mon)
by mjg59 (subscriber, #23239)
[Link] (2 responses)
Most users aren't going to have any of these private keys, so Microsoft mandate that it be possible to enter a "custom mode". The semantics of this aren't well defined, so it's valid for an implementation to manage it either by offering a firmware UI interface to enrol keys directly or to simply let the user delete all the existing keys which results in the system transitioning back to setup mode.
If you have unauthenticated management interfaces on your network then you obviously deserve to lose.
Posted Jun 12, 2012 7:10 UTC (Tue)
by nix (subscriber, #2304)
[Link] (1 responses)
I have horrible visions of vendors' getting the setup mode wrong such that the Pk is changed instead, breaking future updates -- but incompetent though most BIOS vendors are, I suppose the Pk is probably burned into the hardware and unchangeable even by an idiot BIOS.
I must say the thought of BIOS vendors writing anything at all to do with crypto fills me with trepidation. I'm somewhat surprised that PCs can even boot reliably, with the boot process under the control of people as bad at writing code as BIOS vendors... adding extra complexity to this, particularly extra complexity designed to fail in the direction of not booting, seems seriously unwise to me.
Posted Jun 12, 2012 7:13 UTC (Tue)
by mjg59 (subscriber, #23239)
[Link]
Posted Jun 7, 2012 11:45 UTC (Thu)
by lemmings (guest, #53618)
[Link] (3 responses)
Posted Jun 7, 2012 13:43 UTC (Thu)
by dgm (subscriber, #49227)
[Link] (1 responses)
Posted Jun 7, 2012 19:13 UTC (Thu)
by apoelstra (subscriber, #75205)
[Link]
But I do think that Microsoft has people bugging them for peace-of-mind. For example, for the most part I keep a pretty careful eye on what's installed on my system and what it does, but I have only a vague idea of what the kernel and systemd are doing, and what they should be allowed to do. So I don't actually know if they're legitimate.
Now, my system is weird and useless enough that I don't worry about these things, but if it was storing customer information, subject to PCI audits, facing the Internet, etc, I would worry.
Posted Jun 14, 2012 3:03 UTC (Thu)
by slashdot (guest, #22014)
[Link]
Other long term problems
Other long term problems
Other long term problems
Other long term problems
If the bit can be reseted with a magic bit manipulation then only few people know how to do it, black-hat paid $250k a shot are part of those mens.
On a side note, I tried to verify the CRC32 of the FLASH at each boot in real mode (no interception possible), but it is completely unusefull: CRC32 changes at each boot, it seems something different (boot counter?) is stored each times the machine reboots.
Basically, we would need a publicly described "file-system format" of the FLASH (simple filename/address/length triplet without non-contigous files and without automatic file creation/growing management) - so that at least the bootloader can display a warning when something which should not change has changed...
Other long term problems
Other long term problems
What I noticed is that the FLASH CRC32 was switching in between two values, then I tried to limit the FLASH checkuming part to what is visible (real-mode address 0xE000:0000 to 0xFFFF:0000) but it did not work neither.
> Any malware which can compromise the bios can install whatever secure boot keys it wants and tell the OS everything is hunky dory.
Other long term problems
Other long term problems
Other long term problems
Other long term problems
Other long term problems
Other long term problems
A few days ago, pjones wasn't even an LWN subscriber.
pjones subscriber ID: 31722 (and he's a guest, so he's not using RH's block subscription -- I assume they have one).
Another subscriber ID in the same thread: 84918.
Other long term problems
A few days ago, pjones wasn't even an LWN subscriber.
pjones subscriber ID: 31722 (and he's a guest, so he's not using RH's block subscription -- I assume they have one). Another subscriber ID in the same thread: 84918.
Other long term problems
Other long term problems
Other long term problems
Other long term problems
So in order to add keys to the white or blacklists, you need to have the private half of a key already.
Aha, that makes sense. (And, again, had I done fifteen minutes of research rather than fifteen minutes' bloviating, I could probably have figured this out myself. So thanks for the information! :) )
Other long term problems
> To help us calibrate how real the threat is, can you please give an actual (non theoretical) example?
Secure boot is the foundation for protecting the entire boot sequence.
Right now, if my Linux machine has init (or equivalent), the kernel, grub (or equivalent) or any other software used in the boot sequence modified by malware, then I am screwed. It could be very difficult to nearly impossible to detect the compromise.
A secure boot enabled system will result in a compromised system failing to boot (assuming all software in the boot sequence chain has its signature checked).
Other long term problems
Other long term problems
Other long term problems
Other long term problems