Truly Erasing Files

Danger Level

This lack of data destruction is a problem if a user wants to remove a confidential file and ensure that no one can see its contents on disk at any future time, including root. The

preferred solution is to overwrite the file's blocks before removing the file. An alternative is to overwrite all the free blocks on the file system to ensure that the free blocks holding the

confidential data get overwritten. This alternative is discussed later in this section. This alternative (overwriting all the free blocks) is good for solving this problem after the fact when someone asks you about this after he already has removed the file. This alternative also will work in cases of files being removed by programs that you do not have control over or do not want to modify. The sendmail program comes to mind here.

Let us consider in-depth the premeditated destruction of data. To ensure that a file system's free blocks do not contain removed confidential data, you need to write over those blocks and this requires some understanding of the ext2 file system. It is an improvement on the

Berkeley Fast File System which is an improvement to the venerable UNIX File System dating back to the early 1970s. User joe wants to ensure erasure of the document

nomerger.mm in /home/joe. This document has confidential details of a failed merger proposal with Pentacorp.

A simple rm nomerger.mm will not work. This is because even the simple command

grep -100 -b Pentacorp /dev/hda3 | more

will search the raw disk device to find blocks with Pentacorp in them, including freed blocks. The -100 flag will show 100 lines before and after each matched line and the -b

flag will show the byte offset in the device file /dev/hda3 so that the spy later can use dd

to look for blocks all around matched ones. You can try this yourself and see it work. Some people incorrectly assume that truncating a file (> nomerger.mm in bash or cp /dev/ null nomerger.mm) will work. It will not. It simply will free the blocks. Again, grep can be used to prove this.

To actually stomp on this data easily, you need to write over the blocks while they still are allocated to the file. One way to do this is with the use of C code or a Perl script. The program discussed here will accomplish this and the code may be integrated into other programs (subject to the stated license restrictions). The program is called overwrite.c

and is available on the CD-ROM. Its source appears in Appendix G. It works by using the

open() system call to open the specified file for writing. The creat() system call would first truncate the file to zero length (and mark those blocks "free" without overwriting them). However, the open() system call allows you to access the existing blocks.

Because Linux allows a program to treat any regular disk file as a random I/O file, a program may write over the existing blocks or parts of them. The kernel's implementation of this is that the existing disk block numbers are used. The overwrite program relies on this implementation. It opens the file for writing and determines how large it is, in bytes.

Then the program uses lseek() to position the starting location for I/O to be the beginning of the file. It then overwrites the entire file, 1 KB at a time, with NUL bytes. Recall that the C language specifies that statically declared data (data declared outside a function or declared static) will be initialized to NULs (binary zeros).

Should you take my word that this program works? Of course not. I tested this program by first creating a file called foo on a file system on /dev/hdc1. I created it via

cat /etc/passwd /etc/group /etc/inetd.conf > /mnt/foo

I then issued the command

debugfs /dev/hdc1

Then, at the

debugfs:

prompt, I entered

stat /foo

One may quit out of debugfs with the "q" command or with Ctrl-D. The debugfs program understands the structure of the ext2 file system and allows analysis and even repair of severely corrupted file systems.

I used debugfs to recover 95 percent of a client's Linux system after he caused "rm -rf /" to occur unintentionally, when he told the system to remove an account name he did not recognize. This account happened to be a system account with a home directory of "/". He had no backups of important work. Certainly the GUI program was poorly designed; I had advised him previously to start doing backups.

Because you will not be specifying -w that would allow writing to the file system, it is safe to invoke debugfs while /dev/hdc1 is mounted. Upon startup, debugfs displays some information about the file system and then prompts with debugfs:. I then issued the

command stat /foo. Recall that all file names given to debugfs are relative to the mount point, /mnt in this case. This shows all information about that file, for example, the "inode"(short for information node).

This information includes a list of the disk block numbers (relative to the start of that partition) that contain the data in the file. In this case for me it showed

Inode: 13 Type: regular Mode: 0644 Flags: 0x0 Version: -665893048

User: 0 Group: 0 Size: 4387 File ACL: 0 Directory ACL: 0

Links: 1 Blockcount: 10

Fragment: Address: 0 Number: 0 Size: 0 ctime: 0x38f2390c -- Mon Apr 10 16:26:52 2000 atime: 0x38f2390c -- Mon Apr 10 16:26:52 2000 mtime: 0x38f2390c -- Mon Apr 10 16:26:52 2000 BLOCKS:

1251781 1251782 1251783 1251784 1251785 TOTAL: 5

I then exited debugfs with Ctrl-D, invoked overwrite /mnt/foo; sync to force any in-memory disk buffers to disk, and reissued the debugfs command. The results were:

Inode: 13 Type: regular Mode: 0644 Flags: 0x0 Version: -665893048

User: 0 Group: 0 Size: 4387 File ACL: 0 Directory ACL: 0

Links: 1 Blockcount: 10

Fragment: Address: 0 Number: 0 Size: 0 ctime: 0x38f23e53 -- Mon Apr 10 16:49:23 2000 atime: 0x38f2390c -- Mon Apr 10 16:26:52 2000 mtime: 0x38f23e53 -- Mon Apr 10 16:49:23 2000 BLOCKS:

1251781 1251782 1251783 1251784 1251785 TOTAL: 5

As you can see, the same blocks are in the file and in the same order, giving convincing evidence of the correctness of the program. A subsequent octal dump verified that the data was overwritten: od /mnt/foo 0000000 000000 000000 000000 000000 000000 000000 000000 000000 * 0010440 000000 000000 0010443

One might worry that the blocks have been freed, and then reallocated in the same order only because the file system was not otherwise active. This theory may be tested by modifying the

overwrite.c program to also open some temporary file and alternate 1 KB writes between the two files.

Even if you write over the blocks that contained confidential data, a "moderately funded" opponent would have no trouble reading the last two or three things that were written onto the disk, using a technique called Magnetic Force Microscopy (MFM). If the nature of your data is such that this is a concern, the program that you can use to prevent this is called Wipe. It repeatedly overwrites particular patterns to the files to be destroyed, causing these "garbage" patterns to be the last few layers. This prevents anyone ever from reading your confidential data.

Wipe may be downloaded from either of the following places and is available on the CD-ROM and Web site:

http://www.debian.org/Packages/unstable/utils/wipe.html http://www.altern.org/berke/wipe/

An alternative to wipe is to use an encrypted file system or to store files on disk only in encrypted form. The latter technique is harder to get right as even an unencrypted editor temporary file would be a security breach. Encrypted file systems are covered in "Encrypted Disk Driver".