[3497] in bugtraq
Re: ftpd bug? Was: bin/1805: Bug in ftpd
daemon@ATHENA.MIT.EDU (Brad.Powell)
Thu Oct 17 15:18:03 1996
Date: Thu, 17 Oct 1996 09:41:08 -0700
Reply-To: "Brad.Powell" <Brad.Powell@West.Sun.COM>
From: "Brad.Powell" <Brad.Powell@West.Sun.COM>
X-To: dills@husc.harvard.edu
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@NETSPACE.ORG>
In article:
>Date: Wed, 16 Oct 1996 14:11:02 -0400
>From: Andrew Dills <dills@husc.harvard.edu>
>Subject: Re: ftpd bug? Was: bin/1805: Bug in ftpd
>X-To: gamble@dxcoms.CERN.CH
>To: Multiple recipients of list BUGTRAQ <BUGTRAQ@NETSPACE.ORG>
>
Andrew writes:
>Do you have core dumps turned off?
>
>I forget where it is in 4.1.1, but under Solaris you can a line in
>/etc/system to set coredump size.
>
>Set it to 0, and you can avoid these problems.
core dump size in /etc/system doesn't do what you want since that has to
do with system core dumps, however your on the right track. :-)
If you were to modify /etc/rc2.d/S72inetsvc and change the (last)
line where inetd starts up to first start up a shell; limit
its corefilesize to zero and have the shell start up /usr/sbin/inetd -s
then all inetd services would not be able to dump a core file.
I used to do this in the old days of 4.1.X for rpc.pwauthd since if an
intruder gained root they could do a gcore on the rpc.pwdauthd and get
whatever system passwords were sitting in there (cleartext). I know if
they already have root big deal right? Well gaining root in one location
shouldn't help breaking other hosts, and unfortunately users/administrators
have a tendancy of re-using passwords accross many hosts. I've seen Sun's
fall because of a bug in VMS (and vice versa) :-) simply because the admin
used the same password on both boxes.
=======================================================================
Brad Powell : brad.powell@Sun.COM
Sr. Network Security Architect/Consultant
Sun Microsystems Inc.
=======================================================================
The views expressed are those of the author and may
not reflect the views of Sun Microsystems Inc.
=======================================================================