What happens when I use 'dd' to overwrite the disk from which Ubuntu is running?

Question

What would happen if I use

sudo dd if=/dev/zero of=/dev/sda

from an Ubuntu install running from /dev/sda?

---

I tried it in a VM, and it appears to correctly have wiped the disk. Will this be the case every time? Is this a secure way to "wipe" an Ubuntu install and all data?

My question is somewhat inspired by:

1. How do I uninstall Ubuntu from a computer?
2. How is 'rm -rf /' able to delete all files in the system?.

Solution 1

Actually, the filesystem is still mounted, and some writes are buffered meaning they are still in RAM waiting to be written to the disk. Let's say dd correctly overwrites everything, and just behind it the buffers are getting flushed and some potentially sensitive data is getting written back to the disk. So no, this is not a secure way of wiping a disk.

You can avoid this issue by first remounting in read-only mode the root filesystem and any other filesystems that are on the disk (or unmounting them completely, but you won't be able to with the root file system), and then, no more writes should be allowed on the filesystems at all (so no buffers to flush) so your command should be safe now, even though it's still a bad idea in case of panic because it takes a long time.

If you want to have some sort of panic delete feature, I suggest encrypting your disk with LUKS (the Ubuntu installer can do that) and then following my answer over on Security Stack Exchange. This involves wiping the cryptheader which is only 2MBs in size and that takes less than a second to overwrite. Then restart the system and the disk encryption keys will be gone from memory, with no ways to restore them since the cryptheader itself is gone as well.

Solution 2

I sacrificed a VM using a slightly more advanced usage of dd borrowed and slightly modified from the Arch Wiki pages.

First install a nice progress meter:

sudo apt-get install pv

And then run the 'enhanced' dd command

sudo openssl enc -aes-256-ctr -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null \
| base64)" -nosalt </dev/zero \
| pv -bartpes "$(sudo blockdev --getsize64 /dev/sda)" \
| sudo dd bs=64K of=/dev/sda

This will leave the disk filled with AES ciphertext. A complete and secure disk wipe? Probably better than your own dd example but nothing is completely safe or guaranteed...

And you owe me one VM :)

References:

• Arch: Securely wipe disk
• Arch: dd - Advanced Example

Solution 3

Short answer: it'll do roughly what you want and then nothing will work. Using dd you're operating at a level below the filesystem which means that any constraints which would apply there are no longer relevant (this doesn't mean that the kernel couldn't prevent you doing this - but it doesn't). Some content from the filesystem is already in memory, for example the kernel and the dd program itself, and some will be in cache. There is a possibility that if the system is in multi-user mode some files may be written back while the dd is in progress, assuming that they actually have changed, and if you're under memory pressure some pages from there may also get swapped out (they should be encrypted and thus unusable after reboot).

Most commands you'd issue following this - including reboot - would not be in the cache and so would not work. So if you're in single user mode, it'll do extremely well, if you're in multiuser mode it'll wipe the vast majority of data. Ideally you should do it booted from some other medium (even stopping on the initrd perhaps) so that you can be sure where all the writes are coming from.

If you want a secure wipe, this won't do the job because there will still be some traces of the original data remaining if you just zero it. Typically you'd want up to three random writes, which would mean copying from /dev/urandom instead of /dev/zero - much slower but safer. Some may suggest that you use /dev/random which is the device for "pure" random data - no pseudo-random - but for this purpose the chance of somebody managing to crack the PRNG seed and successfully mask out the data is essentially negligible.

If you're really paranoid, you need to throw the storage device into a furnace so that it demagnetises/discharges.

Solution 4

It will as it did in your VM wipe the disk and render your system unusable.

However if you have a sort of 'panic deletion' in mind dd might not be fast enough for that and I'm not sure if there are faster commands or programs providing it in that case.

Solution 5

It should work, the running process is held in Ram and does not need the disk. I would use a live system running from cd or usb anyway. There is even dban, a specialized live linux for disk wiping.

Overwriting your disk with zeros is save, but if you are paranoid enough or have legal rules you can overwrite with random data multiple times.

Be carefull when using ssd overwriting does not guarantee the deletion of all data because of wear leveling.

If you use full disk encryption (luks) you do not have to delete the full disk, deleting the luks header is enough.

View more solutions

Comments

[André Borie]

Also related: security.stackexchange.com/questions/106131/…

[Stormlord]

Can you give an example on how the syntax would be if one would rather fill the disk with zeros (if=/dev/zero) using dd and pv please?

[someonewithpc]

@Stormlord You just pipe it through pv (pipe viewer), so dd if=/dev/zero | pv | dd of=/dev/sdX

[JonasCz]

You don't need to sacrifice a VM - just make a snapshot beforehand, and restore when you're done :-)

[Casey]

Do you remember the dd challenge? This was years ago, but they offered a bounty to any company who could recover any data from a hard drive that had been zeroed over once. They had no takers.

[R.. GitHub STOP HELPING ICE]

The "three times" thing is utter nonsense. Random data 1 time is certainly unrecoverable. Even zeros will be prohibitively expensive to recover from (see @Casey's comment). Maybe if the bounty were $1b or so they'd have takers...

[mckenzm]

So even if there is some write-behind, the total result is steganographically complex. Without the "garbage" it would otherwise be simple to hexdump the disk to find non-zero values.

[mckenzm]

Depends on your budget, and the tech of the disk. If it is a platter, you may be able to get data. Even with "vertical" magnetic technology. The more volatile the memory, the safer you are.