[1232] in linux-security and linux-alert archive
[linux-security] Re: ftpd bug? Was: bin/1805: Bug in ftpd (fwd)
daemon@ATHENA.MIT.EDU (Derek Elder)
Fri Oct 18 02:36:02 1996
Date: Thu, 17 Oct 1996 12:06:40 -0500 (CDT)
From: Derek Elder <djelder@accessus.net>
To: linux-security@tarsier.cv.nrao.edu
Making sure this is looked at...
| Derek Elder V.P., Network Operations|
| djelder@accessus.net 888-637-3638 Ext. 21 |
>Return-Path: ssl-lists-owner@mincom.com
>From: Tim Hudson <tjh@mincom.com>
>Subject: Re: ftpd bug? Was: bin/1805: Bug in ftpd
>To: ssl-users@mincom.com
>Date: Thu, 17 Oct 1996 15:21:10 +1000 (EST)
>Reply-To: tjh@mincom.com
>Sender: ssl-lists-owner@mincom.com
>
>
>According to Francis Liu:
>> There is a discussion going on bugtraq about how ftpd can dump core
>> exposing shadow passwords in the core file. Some people have also
>> managed to make it follow symbolic links -> overwriting arbitrary files.
>>
>> I've managed to get a core dump using SSLftp 0.9 (so I guess I can
>> make it overwrite files), but I haven't managed to get the shadow
>> passwords, yet.
>>
>> Apparently the problem is in the wu-ftpd code somewhere.
>>
>> > logon via ftp with your regular user/password,
>> > ftp> cd /tmp
>> > ftp> user root wrongpasswd
>> > ftp> quote pasv
>
> Actually the problem is in the base BSD ftpd code ... which most Unix
>varients have inherited these days - don't blame wu for this bug.
>The fix is (as usual) rather simple ...
>
> In ftpd/ftpd.c edit the function passive() to check for a null pw and
>then return an error message. You may want to add logging of attempted
>attacks if you are interested in tracking down problem users who don't know
>how to hide effectively.
>
> /* don't let passive be set unless we are logged in!
> * - this stops one of the core-dump holes in ftpd
> * --tjh
> */
> if (pw==NULL) {
> perror_reply(425, "Open passive connection denied - not logged in");
> return;
> }
>
> Alternatively you can change the ftpd code to block all core dumping
>signals and log an error message an exit ... or perhaps have a more
>pervasive check that the user is connected before allowing any of these
>sort of commands to be invoked.
>
> The first patch is included in SSLftp[d]-0.10 due out in the next
>few days.
>
>Tim.
>
>
