[17145] in bugtraq
Re: Shred 1.0 Bug Report
daemon@ATHENA.MIT.EDU (Guenther H. Leber)
Tue Oct 10 23:11:43 2000
Mail-Followup-To: BUGTRAQ@SECURITYFOCUS.COM
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Message-Id: <20001010235009.A2573@sothis.heaven.gams.at>
Date: Tue, 10 Oct 2000 23:50:09 +0200
Reply-To: "Guenther H. Leber" <gleber@GAMS.AT>
From: "Guenther H. Leber" <gleber@GAMS.AT>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <39E33997.94F3F948@mail.sprint.com>
On Tue, Oct 10, 2000 at 08:45:27AM -0700, Jeff Harlan wrote:
> Greetings,
>
> 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
[...]
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
