4

Preface

I searched for an answer to my question and found related questions which do not cover my question completely. Like:
On SSD deleting:
Can Widped SSD Data be recovered
How to securely delete inside Virtual Machine

The second question gets close to what I want to know. And I already know that due to features of an ssd it is not easy secure erasing single files on SSD. But I wonder if there is a missing link between vbox disk and ssd to prevent recovering files deleted inside a virtualbox OS.

my scenario: Windows host running VirtualBox on an SSD. VirtualBox client is linux/ubuntu

tl;dr my question:
If I securely wipe a file in my virtual machine with an appropriate tool (wipe or the like) is it reasonably well deleted?

Some more thoughts

My thinking is: Possibly: The VBox hard disk emulation might overwrite the correct "logical" bytes on the vbox disk. Even though that the real bytes on the SSD are not overwritten they do not have any information on where the bits belong to because only the VBox hard disk driver could make links from its file system. And this information might be destroyed.

Anyone know if this would work?

Another option would be: What if I overwrite free space inside virtualbox with zeros and then shrink the virtualbox Disk?

Uwe Hafner
  • 143
  • 6
  • Both of those questions have answers indicating that it's not secure, what makes you think this is different? – AndrolGenhald Jan 23 '18 at 15:16
  • Solid state and hard drives store data in 4k (or 512b) sectors, even if all files were perfectly fragmented (which is extremely unlikely) there is still quite a lot that can be recovered. – AndrolGenhald Jan 23 '18 at 15:17
  • you could try FDE on the host and VDisk and store your Virtual box files inside an encrypted hidden volume. mount the volume when you want access to that virtual box when you wish to delete it do not save any keys and forget the one for the hidden volume. when its time to get rid of your SSD or repurpose it, just encrypted everything with new keys, do not back them up and delete the partition. you should try to avoid writing layers of zeros, its not a spin drive. – TheHidden Jan 23 '18 at 17:05
  • @AndrolGenhald You are right that the answers are indicating it but not for sure. I was looking for some background info like the 1-to-1 mapping. – Uwe Hafner Jan 24 '18 at 07:41
  • TheHidden is right. If you want to make it secure so no one can read it back later, you'll want to use encryption from day 1. Then you can throw away your drive and it will still be encrypted so secure. – Alexis Wilke Mar 10 '22 at 19:51

2 Answers2

3

No, it's not secure.

Wiping a file in a virtual machine will wipe out the corresponding bytes in the virtual disk file: every VM I'm aware of does a 1-to-1 mapping* between virtual disk sectors and parts of the disk file. However, that doesn't mean the data will be wiped out on the underlying disk: solid-state drives perform wear leveling, so successive writes to the same logical sector will almost never result in writes to the same physical sector.

* Actually, most use sparse files, where never-used parts of the disk simply aren't present in the file, but this doesn't change the situation.

Mark
  • 34,390
  • 9
  • 85
  • 134
  • 1-to-1 mapping was an info I was looking for. Was thinking that through the levels of indirection it might not be that easy. But looks like it is. – Uwe Hafner Jan 24 '18 at 07:44
1

Typically sector in VM matches sector on Host so if you shred file in VM it is effectively shredded on Host.

However this may not erase all copies of this file created when editing it. Editors keep backup files and if not, overwriting the file does not guarantee it will be overwritten over the same blocks. It's because during overwrite, the file is firstly truncated to 0, blocks are released to filesystem, and then the file is written to free blocks and there's no guarantee that it will write to the same blocks.

shred which is command for shredding files, does not truncate the file but overwrites blocks on which the file is stored and it rounds its length to the block size, so if you have file which is 1kb it will shred the whole 4kb block.

If you have remaining copies of the file, you would need to fill up the free space with zeros or with random data after deleting your file.

In rare circumstances when host filesystem has copy-on-write enabled like default btrfs, this might not work. It is because when you shred the file it creates the new copy and leaves the old one. In practice, it is major performance hit so nobody is using btfs with copy-on-write to host VM images.

Aria
  • 2,706
  • 11
  • 19
  • You overlooked wear-leveling, which is the primary reason both of the answers to the linked questions say it's not secure. – AndrolGenhald Jan 23 '18 at 18:27
  • I think wear-levelling doesnt affect it because copy on write of SSDs does not leave data in old blocks. This is easy verifiable with scan of /dev/sda. – Aria Jan 23 '18 at 18:52
  • Go read the answers to the other questions. The data on the SSD isn't directly accessible by the kernel, it's accessed through the flash controller which handles the wear leveling. You have no way to confirm that the data isn't there anymore. And then there are failing sectors as well, which are remapped but may still contain data (for both SSDs and HDDs). – AndrolGenhald Jan 23 '18 at 20:42