2007-06-26
The problem of sensitive data being leaked through the re-use of storage media is by now well-documented. This is unfortunately a reasonably common occurrence, as shown by various stories of sensitive media being lost or sold ( [1], [2], [3]). However the problem isn't just limited to those files which are left intact when the media is disposed of. To quote Wikipedia: "Slack space or file slack is the area between the end of a file and the end of the last cluster or sector used by that file. This area is simply wasted storage potential, so file systems that use smaller clusters utilize the disk space more effectively." [4]. You will notice this if you have lots of files which are very small; a correspondingly large amount of space on your disk will be wasted. However a greater problem is that some of your data which you thought had been overwritten, is still available to any casual snoopers who come into possession of your storage media. This includes attackers who manage to obtain root access to one of your servers, even if they are not physically present.
How bad is the problem?
In a simple filesystem, with 1Kb blocks, if a file of 973 bytes is overwritten by a file of 744 bytes, there will be 229 bytes of the original file which will not be overwritten. Most files are not this short, but the same effect will happen with the last block. Depending on what your data is, this may or may not be a problem; a comma separated file comprising names, addresses and other confidential data may leak too much data for comfort in this situation.
We analyzed a particular model to discover how long it takes blocks in a filesystem to be recycled. The experimental method is to write a string into each 512-byte block in a 64Mb VFAT filesystem - this was chosen because it corresponds to a USB pen drive I possess. While most pen drives are now bigger than 64Mb, the increase in size may well make things worse, as there is less chance of overwriting a particular block. Then files were copied randomly from the filesystem of a Linux installation to the USB pen drive.
Figure 1. Decay of file system blocks as files are copied to the partition. No files are deleted.
In Figure 1, we created a file containing a particular string in each 512-byte block. The VFAT filesystem was then created within this file, and files were repeatedly copied from the hard disk onto the pen drive until it was full. You can see that by the time 3,200 files have been copied the majority of the original blocks have been overwritten. The remaining ones, around 4-5%, are assumed to be in the slack space on the file system. Obviously file systems which tend to have smaller blocks will have less slack space and therefore will leak less data in this manner.
Figure 2. Decay of file system blocks over time. Files are being deleted and new files copied. In Figure 2, we have altered the simulation so that it deletes files randomly while continuing to copy new files to the file system, so that it doesn't remain full and hence static as in the previous example. Although the number of original blocks left intact appears to drop off to near zero, we can see more detail in Figure 3 below:
Figure 3. Decay of file system blocks over time. Files are being deleted and new files copied. Figure 3 is an enlargement of part of the graph in Figure 2. This shows that between 3,700 and 15,700 files copied the number of blocks intact is only decaying gradually. At the end of the simulation there are still 0.4% of the original blocks left, which could be a considerable amount of data on a larger disk. (0.4% of a 2Gb pen drive is 8Mb.)
