Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A key is available in a virtual machine memory dump #2

Open
itdoginfo opened this issue Oct 18, 2019 · 6 comments
Open

A key is available in a virtual machine memory dump #2

itdoginfo opened this issue Oct 18, 2019 · 6 comments

Comments

@itdoginfo
Copy link

I use kvm on Ubuntu 18.04, VM with Debian 10 and 9. Tried with xfce and no gui, if that makes sense.
During installation Debian, encrypted the disk. Nothing special, lvm + luks.
When the system is loaded, I make memory dump

virsh dump debian deb.dump --memory-only

And find aes in dump

sudo ./findaes-1.2/findaes deb.dump
Searching deb.dump
Found AES-256 key schedule at offset 0x36c35058: 
9e 36 d8 ae 32 ec 5a 91 a5 13 16 0f 71 63 90 dd 13 ed ca fc 99 3d bd 57 12 07 bf ae de 2d 96 2b 
Found AES-256 key schedule at offset 0x36c35258: 
12 1d 69 55 9f 53 ba d7 ef 0b 46 91 85 2a 13 28 e9 fe 7d 87 f6 09 62 ec 81 92 d6 fa e3 35 32 75 
Found AES-128 key schedule at offset 0x3a222058: 
3c ea 72 1d 4d cf f1 9a 77 e8 ba e9 6a ad 7e 44 

Then install debian-luks-suspend, doing reboot

Enter pass and repeat

virsh dump debian deb2.dump --memory-only

Domain debian dumped to deb2.dump
                                                                                                                                                                                     sudo ./findaes-1.2/findaes deb2.dump
Searching deb2.dump
Found AES-256 key schedule at offset 0x36c35058: 
9e 36 d8 ae 32 ec 5a 91 a5 13 16 0f 71 63 90 dd 13 ed ca fc 99 3d bd 57 12 07 bf ae de 2d 96 2b 
Found AES-256 key schedule at offset 0x36c35258: 
12 1d 69 55 9f 53 ba d7 ef 0b 46 91 85 2a 13 28 e9 fe 7d 87 f6 09 62 ec 81 92 d6 fa e3 35 32 75 
Found AES-128 key schedule at offset 0x3a222058: 
3c ea 72 1d 4d cf f1 9a 77 e8 ba e9 6a ad 7e 44 

As you can see, the key is still available. I was able to open an encrypted container by converting this key.
I also tried to suspend the VM and make dump. The result is the same

Maybe I misunderstood the purpose of luks-suspend?
Let me know if you need any details

@nailfarmer
Copy link
Owner

nailfarmer commented Oct 18, 2019

Hi @itdoginfo,

The purpose of luks-suspend is to close an encrypted luks volume when suspending to ram, and then to open it when resuming from S3 sleep. It is a wrapper around the luks cryptsetup tool. If this software is running as expected, the key should not be in memory while the machine is suspended.

How did you suspend the VM? Did you use the xfce gui, run systemctl suspend, execute a virsh suspend command, or something else?

Thanks for your assistance!

@itdoginfo
Copy link
Author

Hello!
Sorry for delay.
I tried two ways:

  1. Only virsh dump
    virsh suspend VM while executing this command
  2. virsh suspend and then virsh dump
    This does not make sense for a dump. But I did it for checking debian-luks-suspend

@t2d
Copy link

t2d commented Oct 29, 2019

@itdoginfo I think the problem here is, that you're not suspending the machine in Linux terms. You just suspend it with libvirt. Therefore, the closing of luks volumes never actually happens. Could this be the case? Do you have to enter the luks password when you're resuming the machine?

@nailfarmer
Copy link
Owner

Thanks @t2d!

For a bit more context:

The proper way to trigger a suspend from virsh is to run virsh dompmsuspend <domain> --target mem. The virsh suspend command pauses the machine state rather than invoking s3 sleep state. But even running a dompmsuspend doesn't get us to a state where we are doing a normal system suspend; it's the equivalent of doing a raw echo "mem" > /sys/power/state. It skips the closing of luks volumes and any other hooks that would normally happen during sleep.

In order to get a proper memory dump of the suspended state, you would need to suspend from inside the guest using systemctl suspend or the equivalent, and do a virsh dump on resume before you enter the disk crypt password. If this is possible, it would require qemu-guest-agent to be installed and functional, and it might require modifying the code to do a qemu-ga guest-agent-suspend instead of an echo mem > /sys/power/state.

@SpikeStrips
Copy link

Salute! Will it work on Debian 9.11?

@nailfarmer
Copy link
Owner

Salute! Will it work on Debian 9.11?

Hi @Stephanie8887 ! It should, but be prepared for occasional freezes on suspend as this code is still in the testing stages, even with a recompiled kernel as described in the README.

On the positive side, this kernel patch has recently been submitted for review, so if it's approved, recompiling the kernel would no longer be necessary for a good experience :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants