Vulnerability

    Shred

Affected

    Shred 1.0

Description

    Jeff Harlan found following.   He ran a test  with Shred v1.0  and
    found  some  unexpected  results.   This  utility  is  supposed to
    overwrite a  file with  several passes  of different  bit patterns
    followed by one random pattern.  The file is then unlinked.   This
    is supposed to  make the file  unrecoverable with utilities  which
    read raw disk blocks.  Using the icat utility from Dan Farmer  and
    Wietze  Venema's  TCT  Toolkit  it  appears  that  the data is not
    overwritten.   This  test  was  done  on  two different RedHat 6.0
    systems.

        http://personal.riverusers.com/~thegrendel/shred-1.0.tar.gz

        [root test]# ls -il shred.me
        1298547 -rw-rw-r--   1 jharlan  jharlan        17 Oct 10 08:25 shred.me
        [root test]# icat /dev/hda5 1298547
        shred this puppy
        [root test]# shred shred.me


        Are you sure you want to delete shred.me? y

        1000 bytes have been overwritten.
        The file shred.me has been destroyed!

        [root test]# icat /dev/hda5 1298547
        shred this puppy
        [root test]#

    In  main()  the  author  of  shred calls overwrite(char *filename)
    several times, which is supposed to write diffent patterns to  the
    file.  Unfortunately the code  of overwrite() is as follows  (from
    shred.c):

        89 long overwrite( char *filename )
        90 {
        [...]
        98       if( NULL == (fp = fopen( filename, "w" ) ) )
        [...]

    The  call to fopen is supposed to open the file, but it will  open
    the file *and* truncate it to zero length instead (see  fopen(3)).
    This  causes  the  data  blocks  of  the  file to be freed and the
    patterns will  be written  to newly  allocated data  blocks on the
    disk.   If  the  block  allocation  algorithm  of  the  filesystem
    chooses the same block(s), which was/were freed by truncating  the
    file, then this program would accidentially work as expected.

Solution

    It is advisable discontinuation of the use of the "shred" package.
    There are no plans to bugfix or update it, since Tom Vier's "wipe"
    package accomplishes the same job, and in a more thorough fashion.

    Just for the record. This is not the case in the latest  fileutils
    packages from GNU.   For example, RH 6.2  ships with version 2  of
    shred  which  has  fixed  this  problem.   Version  4.0p  of GNU's
    fileutils is not vulnerable as well.

    Programs like shred are particularly bad, they offer a false sense
    of security, this instance shows a complete lack of  understanding
    of how most UNIX filesystems are implemented.

    Shred won't work reliably on:

        a) data logging filesystems
        b) transactional filesystems
        c) filesystems that perform online defrag (FreeBSD-FFS+reallockblks)
        d) filesystems that offer snapshot capabilities.
        e) (well there's more)

    Programs like this offer a false sense of security, the proper way
    to do  it is  to implement  some sort  of 'scrub(2)'  syscall that
    informs the filesystem code  to accomplish the task  otherwise you
    risk  missing  the  data  on  the  disk.   There  is no way to for
    something like this working entirely from userland on an  advanced
    filesystem without its assistance.

    The only way  to be somewhat  sure (high degree  of confidence, oh
    yeah) is to keep the file  encrypted on the disk at all  times and
    only decrypt  it in  memory (which  unfortunately also  means swap
    partitions  nowadays).   OpenBSD  has  such  a  beastie, and it is
    possible in other  OS's.  If  you want to  be really paranoid  you
    could have a program wipe swap as part of shutdown, one option  is
    http://wipe.sourceforge.net/.  For  example in Linux  use swapoff,
    then wipe the device(s) that had the swap partition.