Re: bin/1805: Bug in ftpd

[marcs () znep com (Marc Slemko)]

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