Hibernation doesn't work?

Posted Sep 13, 2012 20:56 UTC (Thu) by mjg59 (subscriber, #23239)
In reply to: Hibernation doesn't work? by PaXTeam
Parent article: LSS: Secure Boot

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.
2) Kernel encrypts the suspend image.
3) Shim (or grub) generates a new keypair and saves the public key. It passes the new private key and the old public key to the kernel, and then wipes the old public key from the variable store.
4) Kernel verifies that the swap image is appropriately signed and then discards the old public key. The new private key is kept so the user can hibernate again.

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] (8 responses)

> 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] (7 responses)

> 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] (6 responses)

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] (4 responses)

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] (3 responses)

> 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
- The fix is to not restore hibernate images
- The proposed signature checking on hibernate images could protect an un-compromised system on disk from being modified before being restored
- There is no security added for a system booted in a VM
- There is no attestation in Secure Boot, a running system can't tell if it's been compromised or not

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] (1 responses)

> 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?