[6158] in bugtraq
Re: Race conditions - patch.
daemon@ATHENA.MIT.EDU (Theo de Raadt)
Mon Feb 23 12:10:29 1998
Date: Mon, 23 Feb 1998 00:42:50 -0700
Reply-To: Theo de Raadt <deraadt@CVS.OPENBSD.ORG>
From: Theo de Raadt <deraadt@CVS.OPENBSD.ORG>
X-To: =?UNKNOWN-8BIT?Q?Micha=B3?= Zalewski <lcamtuf@BOSS.STASZIC.WAW.PL>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: Your message of "Sun, 22 Feb 1998 14:13:02 +0100."
<01bd3f93$9a8fce20$LocalHost@LCAMTUF>
> Here's my kernel patch. This one should finally (?) stop typical
> race conditions, including pipe attacks and regular file races.
> This solution is radical (disallows writing to not-your pipes and
> files in +t directories), but works fine. Even if any program
> fails, it may be easily patched to store it's files in eg. /tmp
> subdir. It's much easier to change one path than to fix a lot
> of vunerable utilities.
I must say this, though I suspect Aleph1 will be starting to get
annoyed at both sides of this silly discussion:
I am quite fascinated at the extent to which people will go to avoid
fixing the /tmp races in the programs in question.
To me it is quite clear that your patches are breaking the
expectations which regular code has in a POSIX/UNIX environment,
ie. expectations that /tmp works.
Perhaps your next patch will make it impossible to create directories
or files in /tmp.
Because, as I am sure you do realize, it is very easy to effect denial
of service attacks by creating a directory where a program expects a
file, or a file where a program expects to create a directory.
So... how much longer is this futile slashing going to continue?
