| |||||||||||||
Hibernation doesn't work?Hibernation doesn't work?Posted Sep 13, 2012 1:46 UTC (Thu) by corbet (editor, #1)In reply to: Hibernation doesn't work? by JoeBuck Parent article: LSS: Secure Boot Signing the dump would require having the private key in the kernel. An attacker who could mess with the hibernation image would likely have little difficulty finding that key; after that, the game is done.
(Log in to post comments)
Hibernation doesn't work? Posted Sep 13, 2012 2:27 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
There's no need to embed private key into the image. You can do it like this:
1) During the initial boot you generate a random keypair in the shim loader. Store the public part the keypair in the UEFI storage. 2) Kernel keeps the private key in RAM during the normal processing. 3) Use this private key to sign the hibernation image and then discard it (of course, taking care not to write it into the image). 4) During boot you first load the known-good-kernel (checked by the shim) which can then retrieve the public key from the shim and check the signature. 5) If signature matches, it then can load the image.
Hibernation doesn't work? Posted Sep 13, 2012 4:22 UTC (Thu) by alonz (subscriber, #815) [Link] You forgot step 6: generate a new keypair for use with the next hibernation (as the process obviously lost the original private key from step 1).
Hibernation doesn't work? Posted Sep 13, 2012 12:10 UTC (Thu) by PaXTeam (subscriber, #24616) [Link]
> 2) Kernel keeps the private key in RAM during the normal processing.
and at this point you're going to provide us with proof that the kernel has no information leaking vulnerabilities, right? ;)
Hibernation doesn't work? Posted Sep 13, 2012 16:53 UTC (Thu) by hummassa (subscriber, #307) [Link]
Yeah (d'oh!), the private key is in RAM, someone can get to it and sign the specially-crafted restore image.
Hibernation doesn't work? Posted Sep 13, 2012 18:46 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Yeah, and it also has no vulnerabilities at all. Any trusted boot system assumes that, so it must be true.
Hibernation doesn't work? Posted Sep 13, 2012 19:32 UTC (Thu) by PaXTeam (subscriber, #24616) [Link]
in other words, it doesn't actually matter where that private key is stored. what did you try to say then?
Hibernation doesn't work? Posted Sep 13, 2012 20:56 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
The aim isn't to prevent modification of the swap image on an existing system (there may be benefits to that, this just isn't what we're concerned about). The aim is to avoid the case where an attacker can drop a malware payload consisting of a legitimately signed Linux bootloader, a legitimately signed Linux kernel and a malware hibernation image that then launches a backdoored OS (not necessarily Linux). If the hibernation key is session-specific then that seems achievable:
1) Shim or grub generates keypair and passes the private key to kernel. The public key is saved in a boot services variable, preventing it being read by the running OS.
Since the key is specific to the combination of the machine and the boot, an attacker shouldn't be able to deploy a pre-packaged attack. Am I missing something?
Hibernation doesn't work? Posted Sep 14, 2012 15:51 UTC (Fri) by hummassa (subscriber, #307) [Link]
> Since the key is specific to the combination of the machine and the boot, an attacker shouldn't be able to deploy a pre-packaged attack. Am I missing something?
The fact that the new private key is in memory and the malware can use it to craft and then sign the restore image, that will be restored normally. Damn, the malware can bypass this altogether and generate the pair on the fly, sign the image, and store the public key in the appropriate place.
Hibernation doesn't work? Posted Sep 14, 2012 16:12 UTC (Fri) by mjg59 (subscriber, #23239) [Link]
> Damn, the malware can bypass this altogether and generate the pair on the fly, sign the image, and store the public key in the appropriate place.
No it can't - you can't set boot services variables from within the OS.
Hibernation doesn't work? Posted Sep 14, 2012 16:51 UTC (Fri) by hummassa (subscriber, #307) [Link]
If the kernel HAS the private key, and will check the signature against a boot service variable-located public key, the malware can sign the restore image with the private key. If the public key is stored anywhere else, the malware can overwrite it with his own public key. Anyway, the malware can boot the compromised system by crafting a restore image, signing it and forcing a reboot. All that WITHOUT asking the user to do anything. And all that with the user thinking that his boot-time environment is perfectly safe.
Hibernation doesn't work? Posted Sep 14, 2012 17:08 UTC (Fri) by mjg59 (subscriber, #23239) [Link]
The malware cannot overwrite the public key. The rest is, like I said, not the attack that we're trying to prevent here. Being able to run code in the kernel means that you can alter kernel state. That's why we're focusing on making it difficult to run code in the kernel.
Hibernation doesn't work? Posted Sep 14, 2012 17:19 UTC (Fri) by raven667 (subscriber, #5198) [Link]
This whole line of reasoning seems wrong. If there is malware running on the system when it is hibernated then the malware will be written to the hibernate volume and restored with it so the system is no more or less compromised, it all seems like a no-op. If the system does not have malware and uses some signing system with a public key in firmware generated on boot and a private key in the kernel which is not written to the hibernate volume then I don't see how one could modify the hibernate volume without being detected.
Even in the case where there is malware running on a system you should still be able to perform a clean boot with verification up to the point where your trust chain stops. Then the problem is post-boot (re)compromise and you can use many tools to combat that, if you can get them into your trusted base.
Hibernation doesn't work? Posted Sep 14, 2012 19:48 UTC (Fri) by hummassa (subscriber, #307) [Link]
> If there is malware running on the system when it is hibernated then the malware will be written to the hibernate volume and restored with it so the system is no more or less compromised, it all seems like a no-op.
No, because crafting a special restore-image/swapfile and forcing a reboot you can, for instance, boot a whole another OS altogether, totally bypassing the "secure" boot nonsense.
> Even in the case where there is malware running on a system you should still be able to perform a clean boot with verification up to the point where your trust chain stops. Then the problem is post-boot (re)compromise and you can use many tools to combat that, if you can get them into your trusted base.
No, because at that point the "phantom" OS can just behave like the "original" OS with a rootkit, rendering symptoms of infection invisible to the original OS.
Suppose the machine is running Windows8, ok? The malware prepares an image that will run some OS that will run Windows8 in an emulated, censored environment that can make a lot of bad things, invisibly to W8. Everytime W8 tries to reboot, it goes thru the hoops again and boots instead the other OS.
Hibernation doesn't work? Posted Sep 14, 2012 20:59 UTC (Fri) by raven667 (subscriber, #5198) [Link]
I don't think your points actually disagree with my points, I think we are actually in agreement on the technical issues.
- Hibernate images are outside the trust boundary because they contain arbitrary code
I don't think Secure Boot attempts or claims to solve the problems of running arbitrary code it only allows you to build a beachhead, ideally an execution chain all the way until user space starts that can't be modified without throwing alarms. That means that re-compromise of a system needs to happen via the normal startup sequence and tools started before the malware can run can potentially block the malware. Once the malware runs it's Blue Pill all the way, you can't trust anything on the system after that.
Hibernation doesn't work? Posted Sep 14, 2012 22:56 UTC (Fri) by mjg59 (subscriber, #23239) [Link]
> No, because crafting a special restore-image/swapfile and forcing a reboot you can, for instance, boot a whole another OS altogether, totally bypassing the "secure" boot nonsense.
Yes, and if you can get private information out of the kernel then you can probably also get private information *into* the kernel, and then you can just make the kernel execute your other OS without doing anything with hibernation.
Hibernation doesn't work? Posted Sep 15, 2012 2:03 UTC (Sat) by raven667 (subscriber, #5198) [Link]
Or run it in a VM, Secure Boot isn't designed to protect from a rogue hypervisor. Secure Boot is a fairly basic tool and only covers a small part of the security process, maybe you were expecting something more?
Hibernation doesn't work? Posted Sep 13, 2012 10:09 UTC (Thu) by etienne (subscriber, #25256) [Link]
What happens when a Windows user hibernate his PC, boots Linux which may change the hibernation image, power downs and then restart Windows hibernation image?
I also note that having multiple Linux distributions on a single PC will be a problem.
Hibernation doesn't work? Posted Sep 13, 2012 13:27 UTC (Thu) by pjones (subscriber, #31722) [Link]
> I also note that having multiple Linux distributions on a single PC will be a problem.
There's nothing with our Secure Boot implementation that prevents this from working exactly as it does now on UEFI systems.
|
|||||||||||||