Encrypting an unregistered disk from command line while no VBoxSVC.exe running may cause data loss

[scottgus1bug]

If the command "VBoxManage encryptmedium" is run on an unregistered disk file while no Virtualbox window is open, data loss may result:

1. Release a good disk from a test guest (make a copy for a backup). Unregister the disk from the Media Manager so it does not show in the list. Close all Virtualbox windows. Ensure that the VboxSVC.exe process has closed.

2. Run the command line on the good disk file.

3. The running of the command will launch a new VBoxSVC.exe to support the command. When the command completes, the associated VBoxSVC.exe will close in a few seconds. If you can get the main Virtualbox window open before the VBoxSVC.exe from the command line closes, the main Virtualbox Window will know about the newly-encrypted disk and use it properly.

4. If you cannot get the main Virtualbox window open before the command's associated VboxSVC.exe closes, then the main Virtualbox windows will not know the disk was encrypted. The DEK for that disk will be lost, and the disk's internal data is scrambled and unusable.

[scottgus1bug]

Suggested solution: Don't command-line-encrypt unregistered disks - require them to be attached to a guest first so the DEK has a home to go to.

[Socratis]

Replying to scottgus1bug:

The DEK for that disk will be lost, and the disk's internal data is scrambled and unusable.

How about ch. 9.31.4 Decrypting encrypted images, it doesn't work? I'll quote the whole chapter! Don't worry, it's small ;)

In some circumstances it might be required to decrypt previously encrypted images. This can be done in the GUI for a complete VM or using VBoxManage with the following command:

VBoxManage encryptmedium "uuid|filename" --oldpassword "file|-"

The only required parameter is the password the image was encrypted with. The options are the same as for encrypting images.

[Thorsten Schöning]

There's a related discussion and another ticket regarding this problem:

​https://forums.virtualbox.org/viewtopic.php?f=1&t=83217

https://www.virtualbox.org/ticket/16781

Quoting chapter 9.31.4 is simply not enough, the interesting part comes before that:

VirtualBox uses the AES algorithm in XTS mode and supports 128 or 256 bit data encryption keys (DEK). The DEK is stored encrypted in the medium properties and is decrypted during VM startup by entering a password which was chosen when the image was encrypted.

Since the DEK is stored as part of the VM configuration file, it is important that it is kept safe. Losing the DEK means that the data stored in the disk images is lost irrecoverably. Having complete and up to date backups of all data related to the VM is the responsibility of the user.

https://www.virtualbox.org/manual/ch09.html#diskencryption

From the docs and simply looking at VirtualBox's config files of VMs it is absolutely clear that only providing a password itself is NOT enough. So this ticket describes very surprising behaviour and my formerly created #16781 describes another one: DEKs are not moved if media is re-attached to other VMs, which can lead to dataloss easily as well if VMs containing DEKs for (now) unrelated media get deleted. Both things should at least be documented very, very clearly in the docs.

[scottgus1bug]

Just to hopefully clarify the above ticket issue:

If a disk that is not attached to a guest is encrypted via command line, and the VBoxSVC.exe that is overseeing the Virtualbox session that encrypted that un-attached disk is allowed to close before the disk gets attached to a guest, the DEK for the encrypted disk is not stored anywhere, and the disk is destroyed (one needs both password and DEK to decrypt or use the disk and the DEK is gone.)

[scottgus1bug]

Another solution: if encrypting unregistered disks is essential to a customer's system, before the disk file is encrypted, write the DEK into a text file called, perhaps, "<diskfilename>.dek" and confirm it was written correctly. Since the DEK for a disk is written in plain text in the .vbox file, writing it in a text file next to the disk file itself should not be a security issue.

Then when a disk is registered with a guest, look for a "<diskfilename>.dek" file in the same folder. If the .dek is found, report the possibility of this disk being encrypted, and ask the user to confirm.

[Socratis]

Replying to scottgus1bug:

... write the DEK into a text file called, perhaps, "<diskfilename>.dek" ...

Excellent idea Scott!!! I see your "<VDI>.dek" idea and I'll raise you. Take the whole idea of the DEK being stored in the ".VBOX" and store it in the ".DEK". Only!

Since the VDI format doesn't provide an extension to include the DEK as metadata (to make the whole thing portable) and the DEK is required, that makes the VDI dependent on another file. As it is now, that's the ".VBOX" file. Well, drop that altogether and make the dependency solely on the ".DEK" file. Simpler, easier to understand/explain, same portability/backup issues, soon enough in the encryption idea for the revisions to be a nuance at the most (for the end users).

... when a disk is registered with a guest ... report the possibility of this disk being encrypted, and ask the user to confirm.

Not a bad idea, but you're going to be asked for the password nonetheless, no? Shouldn't that be enough of a "hint"? ;)

[aeichner]

Hi, we are going to discuss the possibilities to get rid of the risk of losing the data internally and implement a solution. However this will be quite a bit of work and won't be available in a maintenance release or the next major release but at some other point in the future. This is just an heads up that we are aware of it. :)