Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


If you are using disk encryption on a VM - where is the password cached?
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

If you are using disk encryption on a VM - where is the password cached?

If you encrypt the boot disk on a laptop the password is cached in the RAM as long as you have typed in the password. So if people have access to your computer, they can use "cold boot attack" to extract your password from the RAM modules.

I then wonder, when you encrypt a virtual machine on Hyper-V or Vmware (workstation) where do the password cache?
Is it on the hosts RAM, so if you use a "cold boot attack" on the host you can extract the password? Or can you extract the password in any other way from the VM as long as it's turned on?

Comments

  • myhken said: where do the password cache? Is it on the hosts RAM,

    I think it must be host RAM as that's the only physical ram present, don't take my words for granted tho.

  • Typically (at least good security practice dictates), the password as such is used only to decrypt the actual key/key-material which is what is used to (symmetrically) encrypt/decrypt the blocks on disk. The actual password itself is not useful any more once the key itself is in-memory for all crypt ops and it is (should be) usually overwritten (zeroed/random whatever) prior to "freeing" (again these are not memory managed locations, so you are typically overwriting the same location to prevent dumping/recovery of the plaintext). Apart from the race condition of a precisely "timed" memory dump, you shouldn't really be able to recover the plaintext password from the dump (but and this is a big but), there are buffers and what not all over the place (in addition to implementation quirks) and who knows where what you typed is saved "temporarily" that possibly enables recovery from such a mem dump.

    I'm not familiar with all the various implementations out there (and who knows what all bugs creep in on account of misinterpretations) but in general the above paragraph should be a sane version of what is to be expected.

    Thanked by 3WSS myhken mksh
  • raindog308raindog308 Administrator, Veteran
    edited January 2018

    What are you storing on someone else’s server in a public datacenter that you’re worried about cold boot attacks?

    I hate to be the one to tell you this, but if the party bus comes, they’ll bring their own portable power and won’t need to cold boot your server. They’ve heard about encrypted hard drives.

    Thanked by 4myhken emg pike netomx
  • KuJoeKuJoe Member, Host Rep

    The key for encrypted VPS disks is stored in the hosts RAM. I've seen people extract the passwords in the past and due to the nature of the technology I doubt that much has changed in this aspect.

    http://rand.pw/howsecure/

  • I see, so there is no way to have a secure VM on a server - even if I only power it on when I need to use it, and then power off again. If anybody access the host while it's powered on, they can extract the password from the hosts RAM?

    What about Vmware, is the password stored in the Vmem file or on the hosts RAM there also?

  • jackbjackb Member, Host Rep
    edited January 2018

    @myhken said:
    I see, so there is no way to have a secure VM on a server - even if I only power it on when I need to use it, and then power off again. If anybody access the host while it's powered on, they can extract the password from the hosts RAM?

    What about Vmware, is the password stored in the Vmem file or on the hosts RAM there also?

    You should assume that anyone with physical access can access your files. FDE makes it prohibitively difficult for a curious, law-breaking vendor; but not impossible. Chances are after a few minutes of your VM being offline, the memory that used to store the key would be repurposed (e.g. host cache for files) and therefore probably safe.

    However if the party van rolls in with a warrant, I'd say you are toast - if the VM is offline, they can just wait until you boot it and put in the password.

    Tl;dr If you're not breaking any laws I doubt anyone would bother.

    Thanked by 1myhken
  • myhken said: cold boot attack

    Take your meds & stop worrying about this, really.

  • emgemg Veteran
    edited January 2018

    @Aidan said:

    myhken said: cold boot attack

    Take your meds & stop worrying about this, really.

    I think @myhken deserves credit for thinking about this problem at all. Unfortunately, there is no simple solution.

    Your VPS provider has full control over your VPS whenever it is running, even if it uses full disk encryption.

    Your next problem is how to unlock the drive at boot time. If your VPS boots automatically, then it must have the key stored locally, which means that your VPS provider can find the key and use it to unlock your VPS' drive.

    If your VPS does not boot automatically, then it will stay down any time there is a power outage, an automatic update that reboots, or just a glitch that forces a reboot. At that point, you must be available to unlock the drive encryption key.

    Your next problem is how to unlock the VPS at boot or restart time. Unless you go to extreme measures to secure the communications between you and your VPS at boot time, your VPS provider can see your network communications, including the passphrase that you use to unlock the drive encryption key. Keep in mind that the VPS has not yet booted, so you need a boot loader that has some type of network-enabled encrypted communications (e.g., SSH) included in the boot loader itself.

    ... and after all that, you still have the problem that your VPS provider has full access and control of your VPS whenever it is booted up and running.

    The bottom line is that there is no way to secure a VPS from the VPS provider, or anyone who has the legal authority to compel the VPS provider to give them access.

    Thanked by 2myhken Xei
  • The bottom line is that there is no way to secure a VPS from the VPS provider

    There's no way to secure anything if physical access is possible, short of setting up a tripwire to blow it all up.

    Thanked by 2myhken lazyt
  • WSSWSS Member

    @Aidan said:

    The bottom line is that there is no way to secure a VPS from the VPS provider

    There's no way to secure anything if physical access is possible, short of setting up a tripwire to blow it all up.

    Still not good enough, since anything attached to the machine other than the power cord is succeptable to getting access to the machine. The fact that it's likely got Intel ME (and BIOS hasn't been updated to mitigate known attacks) is more than enough to get into the machine from any largeish government function.

    If they want you, they've got you. It's that simple. Now, the question becomes if you've done anything wrong, rather than your encrypted data blob which they've likely got access to.

  • @WSS said: If they want you, they've got you.

    Exactly. If one of those 3 letter agencies really wants you (for whatever, possibly misguided even, reason), there's really not much hope in these little things about keys and encryption algos and what not. You've got as big a problem as you'll likely ever have and I'm not really sure there's any way out of it (apart from torture or total surrender and I really don't quite know the difference between the two).

    Of course the obligatory xkcd.

    Thanked by 1Aidan
  • If they control the host node you should assume they can snapshot the VM and work on the image at their leisure. With dedi or colo you can make things a lot harder, basically by encrypting the ram with newer cpu features like Intel SGX or AMD SME/SEV:

    https://semiaccurate.com/2017/06/22/amds-epyc-major-advance-security/

    Thanked by 2nullnothere myhken
  • WSSWSS Member

    I read it up to this: (Note: SemiAccurate feels Intel’s security architecture is correct, everything else is abjectly broken)

    Thanked by 2nullnothere myhken
  • deankdeank Member, Troll

    Isn't Semiaccurate run by a (hardcore) diehard AMD fan? The dude also hates Nvidia from what I hear.

    Thanked by 1myhken
  • @willie said: ...basically by encrypting the ram...

    @WSS said: I read it up to this...

    I read it and I had this strange deja-vu-esque feeling of what just happened with the meltdown+spectre issue (and the slightly older Intel ME chip issue) and IMHO, I'm not willing to trust too much complexity inside silicon. Here we are struggling to keep kernel space and user space cleanly separated and all of a sudden, its as if someone came and said trust the chip/cpu to keep keys separate (yada yada ...) and I'm just flabbergasted. Granted (probably) it's just me, the eternal doubting Thomas, but I'd say this is still quite far from a usable+dependable model as of now. I'd definitely like to see it evolve but I have no faith (trust?) in getting it done correctly so deep down in silicon (where the expense of a bug fix is you know how painful).

    Thanked by 1myhken
  • WSSWSS Member

    @nullnothere said:
    I read it and I had this strange )

    You can spraypaint a turd and say it's a nugget, but it's still a shitnugget.deja-vu-esque feeling of what just happened with the meltdown+spectre issue (and the slightly older Intel ME chip issue) and IMHO, I'm not willing to trust too much complexity inside silicon. Here we are struggling to keep kernel space and user space cleanly separated and all of a sudden, its as if someone came and said trust the chip/cpu to keep keys separate (yada yada ...) and I'm just flabbergasted. Granted (probably) it's just me, the eternal doubting Thomas, but I'd say this is still quite far from a usable+dependable model as of now. I'd definitely like to see it evolve but I have no faith (trust?) in getting it done correctly so deep down in silicon (where the expense of a bug fix is you know how painful).

    The whole issue is that it is still decrypted somewhere, and all management-below-the-surface tools are designed to mitigate the CPU involvement. Hell, Intel ME has direct network access, transparent to the user.

    You can spraypaint a turd and say it's a nugget, but it's still a shitnugget.

    Thanked by 1myhken
  • Yeah I think there are already some attacks against on-chip enclaves, but the attacker has to know what they're doing and have possibly have direct access to the hardware. There are also external TPM modules. Again those probably can't keep out 3-letter agencies, but I know of some big internet companies using them to protect colo servers in certain countries where they don't trust the data centers to not mess with them.

    If you're trying to encrypt a whole hard disk there will necessary be keys and plaintext in ram (unless the ram is encrypted). If it's just for a few things like passwords there are approaches like AWS Parameter Store, which protects keys with a hardware module (AWS KMS, key management service) and is accessible only to credentialed machines on an authenticated VLAN. I'd be interested to know if it's available on Lightsail. I've been wanting to implement something like it on a small dedi, and it's one of my half-baked plans for my Scaleway C1.

    Thanked by 1myhken
  • mfsmfs Banned, Member
    edited January 2018

    All this reminded me ye olde TRESOR patch, used to move secrets from RAM to CPU registers (that only moves the problem from the RAM to the CPU and "CPU registers are currently vulnerable on virtual machines, since they are reset during simulated hardware resets but not during software resets" )

    As already stated, if the server is not under your physical control, you can't really pretend to secure it against third parties. Physical security is essential in any security policy and one could juggle around with software-side tricks only this much

    Thanked by 1myhken
  • sureiamsureiam Member
    edited January 2018

    And now you understand the value of AMDs SEV on their new EPYC server CPUs

    Thanked by 2Aidan myhken
  • And now you understand the value of AMDs SEV on their new EPYC server CPUs

    Damn, that's epic.

    Thanked by 1myhken
  • WSSWSS Member
    edited January 2018

    So, it doesn't let someone with local admin access to scrape known data from RAM. Woop-de-fucking do? I mean, doesn't anyone remember /dev/mem is right fucking there?

    e.g.

    %sudo dd if=/dev/mem bs=1k skip=768 count=256 2>/dev/null | strings -n 8 | grep -i bios
    00IBM VGA Compatible BIOS. 
    BIOS_DATA_BLOCK 
    2089Sandybridge NB VBIOS 2089v11 15" Macallan-KrugSNB-Brooks-Panel #7, updated binaries only
    Intel(R)Sandybridge Mobile Graphics Chipset Accelerated VGA BIOS
    

    What the above limits is a localized admin snooping in RAM. If they've got that ability, they can always go promiscuous and attack that way if the encoding is trivial enough. This fixes one problem but completely avoids the other problems we're now dealing with on several platforms.

    Thanked by 1myhken
  • sureiamsureiam Member
    edited January 2018

    @WSS said:
    So, it doesn't let someone with local admin access to scrape known data from RAM. Woop-de-fucking do? I mean, doesn't anyone remember /dev/mem is right fucking there?

    e.g.

    %sudo dd if=/dev/mem bs=1k skip=768 count=256 2>/dev/null | strings -n 8 | grep -i bios
    00IBM VGA Compatible BIOS. 
    BIOS_DATA_BLOCK 
    2089Sandybridge NB VBIOS 2089v11 15" Macallan-KrugSNB-Brooks-Panel #7, updated binaries only
    Intel(R)Sandybridge Mobile Graphics Chipset Accelerated VGA BIOS
    

    What the above limits is a localized admin snooping in RAM. If they've got that ability, they can always go promiscuous and attack that way if the encoding is trivial enough. This fixes one problem but completely avoids the other problems we're now dealing with on several platforms.

    From my understanding it's also stored there encrypted. It's de-encrypted by the VM, in the VM. So it would be accessible from within the VM but not outside of it.

    Thanked by 1myhken
  • WSSWSS Member

    @sureiam said:
    From my understanding it's also stored there encrypted. It's de-encrypted by the VM, in the VM. So it would be accessible from within the VM but not outside of it.

    Yes. I was attempting to state what is currently happening and is possible. If someone has ring0 on your machine, you've got more to worry about than that RAM being snooped- because even though that data is encoded, unless it's completely transient, it will have some artifacts, somewhere. The fact that it's encoded is useful; This is a good move forward for handling compliance issues, but it's still kind of a "Well, that's one minor issue.. now how about Spectre, et al?

    Thanked by 1myhken
  • emgemg Veteran

    I don't know enough about the subtleties of virtualization technologies such as OpenVZ and KVM, but I assume that the host node does its own paging and swapping, and customer VPS data could end up there, too.

    Regarding encrypted RAM, solutions are not yet very mature, and there are ways to break them. Besides, CPU registers and cache are virtual on VPSs, so the VPS provider can see the plaintext from the host node.

    Thanked by 1myhken
  • KuJoeKuJoe Member, Host Rep

    Bottom line, if you're hosting sensitive data then don't host it in a shared environment (including renting dedicated servers).

    Thanked by 2myhken emg
  • emgemg Veteran

    This is a longstanding problem in security. How do you secure data within an object and the processing that it performs, from a person who has physical possession of that object? The problem applies to smartcards, credit cards, stored value cards, DVD and Blu-ray players, John Deere tractors, and much more.

    Thanked by 1jetchirag
  • @emg has got it largely correct. Listen to him and take his advice.

    I'd like to add that your question makes no sense as any security question invariably must specify a context (which you more or less did) and, very importantly, Eve, against whom you want to protect.

    Very roughly speaking you can plan based on the assumption of cost/security inversion (which you may know as something like "80% of any software cost 20% of resources and effort and the other 20% cost 80%") in a rather brutal version.

    Translation: Protection against a noisy spouse is "cheap", against a nosy hoster is much more complicated and expensive, a.s.o. At the high end it largely boils down to "how serious is nsa about getting at your stuff". Well noted, even if the answer were "mildly" we'd already talk about a range far beyond ssl based toys.

    Brutal short version for you and your concrete question: No. If you need to ask such a question you can not protect your VPS (or a dedi) against a competent and determined hoster.

Sign In or Register to comment.