Re: Shred 1.0 Bug Report

[Frank Wiles <frank () WILES ORG>]

 .------[ Guenther H. Leber wrote (2000/10/10 at 23:50:09) ]------
 |
 |  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.
 |
 |  -GünthER
 |  --
 |  GünthER H. Leber @ home          PGP KeyID: 1024/68279259
 |  PGP Public Key: https://www.luga.at/pgppubkeys/68279259.asc
 |  PGP Fingerprint:   4B 12 AD B5 4E ED AB 56  F7 3F B2 02 25 FD 95 98
 `-------------------------------------------------

    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.

 ---------------------------------
   Frank Wiles <frank () wiles org>
   http://frank.wiles.org
 ---------------------------------