by redmail.netbsd.org with SMTP; 25 Jan 2000 08:36:55 -0000
 by hrothgar.gw.com (8.9.3/8.8.6.Beta0/2.1.kim) with USENET id DAA25112
 for tech-security@netbsd.org; Tue, 25 Jan 2000 03:21:03 -0500 (EST)
	for tech-security@netbsd.org (tech-security@netbsd.org)
To: tech-security@netbsd.org
Date: Tue, 25 Jan 2000 08:20:20 GMT
From: christos@zoulas.com (Christos Zoulas)
Message-ID: <Fovttw.JBn@tac.nyc.ny.us>
Organization: Trans-Atlantic Communications
References: <Pine.NEB.4.21.0001210042480.621-100000@oblivion.mono.org>, <20000125011522.A1713@marvin.ece.utexas.edu>
Subject: Re: make advisory

In article <20000125011522.A1713@marvin.ece.utexas.edu>,
Brian C. Grayson <bgrayson@netbsd.org> wrote:
>On Fri, Jan 21, 2000 at 12:43:24AM +0000, David Brownlee wrote:
>...
>> However make(1) uses the temporary file in an insecure way, repeatedly
>> deleting and reusing the same file name for the entire life of the
>> program. This makes it vulnerable to a race condition wherein a
>> malicious user could observe the name of the temporary file being
>> used, and replace the contents of a later instance of the file with
>> her desired commands after the legitimate commands have been written.
>
>  If the temp file is mode 644, how could malicious, unprivileged
>user B modify it after it has been written, but before it has
>been read?  Plus, doesn't it make it difficult for it to be a
>hole if the file is never closed before forking, and the child
>only does a rewind?  Am I missing something?  :)

watch /tmp for files generated by make.
loop around trying to create the file with your own contents; eventually
make will delete its own file, and your create will create the file
before make gets around to re-create it.

christos