[3891] in bugtraq
Re: BoS: serious security bug in wu-ftpd v2.4
daemon@ATHENA.MIT.EDU (Dave Kinchlea)
Sun Jan 5 21:22:46 1997
Date: Sun, 5 Jan 1997 14:37:22 -0800
Reply-To: Dave Kinchlea <security@kinch.ark.com>
From: Dave Kinchlea <security@kinch.ark.com>
X-To: best-of-security@suburbia.net
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@netspace.org>
In-Reply-To: <199701042356.SAA10535@spike.porcupine.org>
On Sat, 4 Jan 1997, Wietse Venema wrote:
>
> The fix as proposed by the author (specific to the dologout()
> function) is probably not sufficient.
>
> There are many places where ftpd temporariliy raises its privilege
> level and could be tractorbeamed away due to the arrival of a
> signal.
>
> Thus, all code fragments that run between seteuid(0) and seteuid(user)
> should be considered critical regions. I recommend that all signals
> be suspended while ftpd does its critical stuff.
I don't pretend to be the security expert Wietse is, so I am taking the
above at face value (couldn't see how it could hurt and it seems to me
that it makes sense).
I looked at the sources and couldn't see any problems with any signals
except for SIGURG and SIGPIPE as any other signal seems to kill the
daemon. So, I created two functions: suspendsigs() and resumesigs() (not
very complicated functions, I just snipped out the original signal
calls, #ifdefs and all, and wrapped them in these functions, changing
the signal handlers to SIG_IGN for suspendsigs()).
I have placed suspendsigs() immediately before all calls to seteuid(0)
and resumesigs() immediately after all calls to seteuid(uid).
This I have done to the RedHat+linux+pam-patched WU-FTP 2.4.2-beta-11
sources. It has not caused any problems, that I can see anyway, it ought
to have cleaned up the aforementioned security problem. If there is
interest, I can make the patches available.
cheers, kinch
