[17155] in bugtraq
Re: Shred 1.0 Bug Report
daemon@ATHENA.MIT.EDU (Frank Wiles)
Wed Oct 11 18:25:25 2000
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Message-ID: <20001011084049.F3902@frank.wiles.org>
Date: Wed, 11 Oct 2000 08:40:49 -0500
Reply-To: Frank Wiles <frank@WILES.ORG>
From: Frank Wiles <frank@WILES.ORG>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <20001010235009.A2573@sothis.heaven.gams.at>; from gleber@GAMS.AT
on Tue, Oct 10, 2000 at 11:50:09PM +0200
.------[ 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
---------------------------------
