This is the mail archive of the
mailing list for the binutils project.
Re: Patch: Initialise new file space to zero for Beos
- To: fnf at www dot ninemoons dot com
- Subject: Re: Patch: Initialise new file space to zero for Beos
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Mon, 20 Sep 1999 08:11:19 -0600
- cc: nickc at cygnus dot co dot uk, binutils at sourceware dot cygnus dot com, pavel at be dot com, dbg at be dot com, mani at be dot com, fnf at be dot com
- Reply-To: law at cygnus dot com
In message <199909201346.GAA02460@toadfish.ninemoons.com>you write:
> Given that this BeOS feature is also a potential security hole, it is
> possible that the low level BeOS behavior may change. This would make
> the original patch Nick provided for bfd, as well as the current
> proposed change, unnecessary. For the moment I think we can live with
> the bfd change, even if we have to maintain it as a Be local change to
> the tools. If indeed the low level behavior of BeOS will NOT change,
> then the more general solution of wedging zero_fseek into the tools
> via the libiberty library may be a better longterm solution.
> Note that the only bug we have observed in the tools to date is the
> assembler writing random data to parts of object files that are
> allocated by seeking past the current end of the file and then never
> overwritten with "real data".
While the only bug you have observed may be the gas bug, you've got a fairly
large security hole.
What's to stop joe badguy from playing the fseek trick to grab a bunch of
disk blocks, then examine them for things he isn't supposed to see? I
would never trust any of my personal data to a system that didn't scrub blocks
free blocks it gave to users.
This kind of hole was fixed on most systems 10-20 years ago.
The way I see it, you have two choices. Scrub in the OS, or scrub at the
application. The former is secure, the latter is not. The former works
even for clueless programmers, the latter does not.