Virtualbox VM encryption can be useful if the host hypervisor is compromised and the unauthorized party uploads data on disk that the host can trivially access (as is frequently the case with ransomware).
I don’t understand your comment at all. Ransomware can encrypt and encrypted virtual machine. If the host is compromised at a privilege level able to read or modify the VM, the vm is also implicitly compromised.
> If the host is compromised at a privilege level able to read
Multi-user systems exists, compromise may be at user-level. Sure, if you have root/SYSTEM level access then all bets are off, but defense is like an ogre - it has layers.
In what scenario can you read/modify virtual box vms on a shared system in which you can’t read enough of a user profile to compromise an active user session to compromise encrypted credentials?
Can you name any scenarios where virtualbox is used in a multi user environment where bare metal shell/fs access is possible that are actually real world? If so I would be telling those entities their architecture is wrong and they would probably save on TCO by re-engineering things.
Defence in depth is a legitimate argument under some use cases, but your argument seems to be in favour of over engineering redundant or theoretical security controls rather than creating actual defensible environments.
> In what scenario can you read/modify virtual box vms on a shared system in which you can’t read enough of a user profile to compromise an active user session to compromise encrypted credentials?
Any type of shared storage, eg NFS/SMB share or even a local disks/RAID for storing VMs.
Also:
>> When Oracle VM VirtualBox has just started up the encrypted VM cannot be opened and it stays inaccessible. Also, the encrypted VM stays inaccessible if it was just registered without a password or the password is incorrect. The user needs to provide the password using VirtualBox Manager or with the following VBoxManage command:
>> VBoxManage encryptvm uuid|vmname addpassword --password filename|- --password-id ID
If such a thing were to run on the host hypervisor, it would be reading an encrypted virtual disk file, not its unencrypted contents (since it would be encrypted at rest on the host).
I suppose it would be possible for the ransomware to be aware of Virtualbox and somehow manipulate Virtualbox's management plane to get access to unencrypted disk data, but unless you're the victim of a targeted ransomware attack, that's pretty unlikely.
You can also rot13 the files to the same effect. Works unless they specifically target your files and are aware of the encryption. Heck, it might be more "secure" because this practice would be more obscure than the encryption they built in.