[8549] in bugtraq
Re: Xinetd /tmp race?
daemon@ATHENA.MIT.EDU (stanislav shalunov)
Sat Nov 14 14:39:19 1998
Date: Sat, 14 Nov 1998 01:13:57 +0300
Reply-To: stanislav shalunov <shalunov@MCCME.RU>
From: stanislav shalunov <shalunov@MCCME.RU>
X-To: Marc Heuse <marc@SUSE.DE>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: Marc Heuse's message of Fri, 13 Nov 1998 09:09:06 +0100
Marc Heuse <marc@SUSE.DE> writes:
> It's hard to secure a create-or-append open call, anyone with an
> idea for a standard solution?
You have missed a word in this sentence: ``It's _not_ hard...''
Translating this pseudocode to documented C is left as an exercise to
the reader. Notice that you cannot unlink instead of move_file (why?)
The chunk of code you inserted would read:
ok = false
while not ok
lstat the file
if file doesn't exist
open the file O_WRONLY|O_CREAT|O_EXCL
if open failed
complain loudly
call move_file
else
ok = true
fi
else
open the file O_WRONLY|O_APPEND
fstat the fd
if inode number is not the same
complain very loundly
close file
else
ok = true;
fi
fi
elihw
The procedure move_file:
ok = false
while not ok
mktemp
rename the file to the generated file name
if rename failed
complain loudly
else
ok = true
fi
elihw
> [This patch leave xinetd vulnerable if /tmp is not sticky, so it's
> not 100% without changing the design or location of how the dump
> should be done.
The solution above does not rely on /tmp being sticky.
> But a system without a sticky /tmp is a problem anyway]
Following this logic you can come to nonsense.
--
Stanislav Shalunov System Administrator, MCCME (http://www.mccme.ru/)
Hiroshima 45--Chernobyl' 86--Windows 95 | Spam? http://www.cauce.org/
