[3463] in bugtraq
Re: bin/1805: Bug in ftpd
daemon@ATHENA.MIT.EDU (Marc Slemko)
Tue Oct 15 10:29:22 1996
Date: Mon, 14 Oct 1996 15:04:51 -0500
Reply-To: Marc Slemko <marcs@znep.com>
From: Marc Slemko <marcs@znep.com>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@netspace.org>
In-Reply-To: <199610141152.EAA23237@freefall.freebsd.org>
On Mon, 14 Oct 1996 rkozak@bdk.lublin.pl wrote:
>
> >Number: 1805
> >Category: bin
> >Synopsis: Bug in ftpd
> >Confidential: no
> >Severity: serious
> >Priority: medium
> >Responsible: freebsd-bugs
> >State: open
> >Class: change-request
> >Submitter-Id: current-users
> >Arrival-Date: Mon Oct 14 05:00:01 PDT 1996
> >Last-Modified:
> >Originator: Robert Kozak
> >Organization:
> BDK w Lublinie S.A.
> >Release: FreeBSD 2.1.5-RELEASE
> >Environment:
> FreeBSD celebris1.bdk.lublin.pl 2.1.5-RELEASE FreeBSD 2.1.5-RELEASE #0: Thu Sep
> 5 13:21:39 MET DST 1996 root@celebris1.bdk.lublin.pl:/usr/src/sys/compile/
> RKKERNEL i386
> >Description:
> While user is connected to server via ftp, the process ftpd is owned
> by this user. When ftpd is abnormally termineted (e.g. kill -11 <ftpd-id>)
> the memory image of this process is writed to file ftpd.core in home dir.
> This file contain encrypted passwords all users on this machine.
>
>
> >How-To-Repeat:
> 1. ftp localhost
> name: username
> password: ****
> 2. On second terminal:
> a) ps -ax | grep localhost
> b) kill -11 <PID>
> c) strings ~/ftpd.core | less (you will see all encrypted passwords).
>
> >Fix:
>
> >Audit-Trail:
> >Unformatted:
>
That isn't nice. I don't think it will contain the passwords of all the
users, just a certain subset of them. This also a problem with older
versions of wuftpd, but the latest beta seems to be fine, although I'm not
sure if that is just a fluke or by design. There are several possible
fixes, but for those that need a temporary fix ASAP, a workaround follows.
There should be no security problems with this, but there could be
something I'm missing.
Create a script. I'll assume it is /usr/local/libexec/ftpd.wrapper. In
it, put the following:
-------
#!/bin/sh
ulimit -c 0
exec /usr/libexec/ftpd $*
-------
where /usr/libexec/ftpd is the path to your old ftp daemon. Modify
/etc/inetd.conf and replace /usr/libexec/ftpd with
/usr/local/libexec/ftpd.wrapper.
What this does is prevent the process from core dumping, therefore
eliminating the problem.
A more permanent fix to the source may be something along the lines of the
below patch (against RELENG_2_1_5_RELEASE), but there should be an
official fix out in the next little bit:
*** /usr/src/libexec/ftpd/ftpd.c Mon Mar 18 04:10:16 1996
--- ftpd.c Mon Oct 14 12:07:21 1996
***************
*** 47,55 ****
--- 47,58 ----
* FTP server.
*/
#include <sys/param.h>
+ #include <sys/time.h>
+ #include <sys/resource.h>
#include <sys/stat.h>
#include <sys/ioctl.h>
#include <sys/socket.h>
+ #include <sys/types.h>
#include <sys/wait.h>
#include <sys/mman.h>
***************
*** 219,227 ****
--- 222,232 ----
int addrlen, ch, on = 1, tos;
char *cp, line[LINE_MAX];
FILE *fd;
+ struct rlimit rlim;
tzset(); /* in case no timezone database in ~ftp */
+
/*
* LOG_NDELAY sets up the logging connection immediately,
* necessary for anonymous ftp's that chroot and can't do it later.
***************
*** 232,237 ****
--- 237,253 ----
syslog(LOG_ERR, "getpeername (%s): %m",argv[0]);
exit(1);
}
+
+ /*
+ * prevent ftpd from dumping core; necessary to prevent a user
+ * from getting a core file with privileged information in
+ */
+ rlim.rlim_cur = rlim.rlim_max = 0;
+ if (setrlimit(RLIMIT_CORE, &rlim) != 0) {
+ syslog(LOG_ERR, "setrlimit(RLIMIT_CORE, &rlim) failed");
+ exit(1);
+ }
+
#ifdef SKEY
strcpy(addr_string, inet_ntoa(his_addr.sin_addr));
#endif
