[dm-crypt] Re: reg: Question on LUKS device's content exposure

[dm-crypt] Re: reg: Question on LUKS device's content exposure

[Michael Kjörling]

On 13 Oct 2021 08:41 +0000, from samsapi01@protonmail.ch (sami0l):
> Suppose my VPS provider wants to view contents of
> /mnt/sdb1_crypt_files, will they be able to mount the device file
> /dev/sda to view the contents at /dev/mapper/sdb1_crypt or
> /mnt/sdb1_crypt_files? Meaning, since /dev/mapper/sdb1_crypt,
> /dev/sdb1 or /mnt/sdb1_crypt_files are *within* the main or root
> /dev/sda will they get access to the files which is within the LUKS
> device (and decrypted at /dev/mapper/sdb1_crypt) too?

Anyone who is in control of the hypervisor will be able to inspect the
VM's portion of the host's RAM, and extract from it anything they
wish, including cryptographic keys or other relevant material (or just
copy it wholesale).

They can also freeze the VM while doing so, ensuring a consistent view
of its state.

They can also snapshot any stable storage, to be transferred to
another system and/or examined at their leisure.

They can also take all the data available to them and spin up a brand
new, identical VM that, to the software running within it, unless it
goes out of the way to the outside world to look, will look pretty
much like nothing ever happened; and _after_ the fact, it's too late.

Basically, realistically, nothing running _inside_ the VM can do very
much about that. At most, it can detect that some operations took
longer than normal to complete.

I believe Intel had a technology at least quite far along which aimed
to mitigate this exact threat, but that still depends to some degree
on you trusting the provider to not lie about offering (and instead
emulating) it.

And of course, there's the age-old issue of how the VM (the VPS)
obtains the passphrase to unlock the LUKS container. If provided
interactively during the boot process, what's to say that the
provider's remote management functionality doesn't log every keypress?
If you connect after boot and unlock the container, then how do you
know for a fact that the kernel's network drivers or the SSH daemon
haven't been tampered with?

_It's someone else's computer._ You're along for the ride. You can put
speedbumps on the road, but that isn't going to stop someone with a
helicopter from flying over them.

If in your threat model this is a problem, then a simple, at least
partial, solution is to rent a whole lockable rack, install your own
server hardware, and put some kind of tamper-detection system in place
to wipe relevant memory and force-shutdown the server immediately if
the rack is opened or otherwise tampered with without proper prior
authorization steps. But that, of course, will be "a bit" more
expensive than most VPS offerings, to the tune of two to three orders
of magnitude (or thereabouts). Another order of magnitude up in cost
gets you your own moderately fast redundant Internet uplink and a
server room of your own where you can install whatever alarm systems
you fancy. Make sure the racks are locked, set the alarm system up
such that it cuts power through the PDUs when it goes off, and you've
made the attack somewhat more difficult.

But not impossible.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
 “Remember when, on the Internet, nobody cared that you were a dog?”

_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de

[dm-crypt] Re: reg: Question on LUKS device's content exposure

[Arno Wagner]

On Thu, Oct 14, 2021 at 21:56:06 CEST, Michael Kjörling wrote:
> On 13 Oct 2021 08:41 +0000, from samsapi01@protonmail.ch (sami0l):
> > Suppose my VPS provider wants to view contents of
> > /mnt/sdb1_crypt_files, will they be able to mount the device file
> > /dev/sda to view the contents at /dev/mapper/sdb1_crypt or
> > /mnt/sdb1_crypt_files? Meaning, since /dev/mapper/sdb1_crypt,
> > /dev/sdb1 or /mnt/sdb1_crypt_files are *within* the main or root
> > /dev/sda will they get access to the files which is within the LUKS
> > device (and decrypted at /dev/mapper/sdb1_crypt) too?
> 
> Anyone who is in control of the hypervisor will be able to inspect the
> VM's portion of the host's RAM, and extract from it anything they
> wish, including cryptographic keys or other relevant material (or just
> copy it wholesale).
[...] 

I completely agree.  

You cannot protect a VM against the hypervisor it is running under 
and you cannot protect against the admin of that hypervisor. 

Even things like CPUs encrypting RAM only serve to protect against
other VMs on the same hardware, not against the hypervisor. 

As to the idea with a dedicated, alerted rack, I know of real-world
installations that do exectly that. This will fail with a competent
attacker as well though, as physical locks and tamper-detection 
switches are not that secure as well.

Regards,
Arno

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier
_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de

[dm-crypt] Re: reg: Question on LUKS device's content exposure

[Michael Kjörling]

On 16 Oct 2021 22:15 +0200, from arno@wagner.name (Arno Wagner):
> As to the idea with a dedicated, alerted rack, I know of real-world
> installations that do exectly that. This will fail with a competent
> attacker as well though, as physical locks and tamper-detection 
> switches are not that secure as well.

Agreed; which is why I specifically said that it'll make the attack
more difficult but not impossible.

As with pretty much anything else security-related, it's really only a
matter of how much money and effort the attacker is willing to throw
at the problem, and how much money and effort the defender is willing
to throw at the problem of discouraging the attacker.

But the simple fact is that inside a VM, the defender is _always_
going to be at a serious disadvantage against an attacker who has
access to the hypervisor (whether legitimately or not). That's just a
consequence of how the technology works.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
 “Remember when, on the Internet, nobody cared that you were a dog?”

_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de