Hibernation doesn't work?

Posted Sep 14, 2012 16:51 UTC (Fri) by hummassa (subscriber, #307)
In reply to: Hibernation doesn't work? by mjg59
Parent article: LSS: Secure Boot

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?