From owner-freebsd-security  Mon Oct 14 15:44:51 1996
Return-Path: owner-security
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id PAA02421
          for security-outgoing; Mon, 14 Oct 1996 15:44:51 -0700 (PDT)
Received: from assaris.sics.se (assaris.sics.se [193.10.66.108])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA02401
          for <freebsd-security@FreeBSD.org>; Mon, 14 Oct 1996 15:44:43 -0700 (PDT)
Received: (from assar@localhost) by assaris.sics.se (8.7.5/8.7.3) id AAA00477; Tue, 15 Oct 1996 00:40:49 +0200 (MET DST)
To: Marc Slemko <marcs@znep.com>
Cc: Guido van Rooij <guido@gvr.win.tue.nl>, freebsd-security@FreeBSD.org
Subject: Re: bin/1805: Bug in ftpd
References: <Pine.BSF.3.95.961014150514.4318G-100000@alive.ampr.ab.ca>
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
From: Assar Westerlund <assar@sics.se>
Date: 15 Oct 1996 00:40:46 +0200
In-Reply-To: Marc Slemko's message of Mon, 14 Oct 1996 15:52:18 -0600 (MDT)
Message-ID: <5lvicd6ufk.fsf@assaris.sics.se>
Lines: 53
X-Mailer: Gnus v5.2.40/Emacs 19.34
Sender: owner-security@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

Marc Slemko <marcs@znep.com> writes:
> On Mon, 14 Oct 1996, Guido van Rooij wrote:
> 
> > Marc Slemko wrote:
> > > 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:
> > > 
> > 
> > the sensitive info are cleared as soon as the info has been used.
> > The same problem could show up with any other suid root program that reads
> > the password databases. (if that is indeed the happening. It might also be
> > that just the users password string is dumped only.)
> 
> I agree that ftpd should be able to dump core if it wants to, but don't
> see an obvious solution that can be implemented in the ftpd code.  From a
> quick look at ftpd.c, it seems to be doing the logical thing and simply
> calling getpwnam(3) to get the user info.  This means that either the
> memory would have to be cleared by getpwnam, or some horribly inefficient
> hack would have to be put in ftpd. 

I think this is a more general problem.  And sometimes it's even
worse.  Look at login:

        /* Discard permissions last so can't get killed and drop core. */
        if (rootlogin)
                (void) setuid(0);
        else
                (void) setuid(pwd->pw_uid);

        if (changepass) {
                int res;
                if ((res=system(_PATH_CHPASS)))
                        sleepexit(1);
        }

        execlp(pwd->pw_shell, tbuf, 0);
        err(1, "%s", pwd->pw_shell);
}

After the setuid, I will be able to make it dump core, or even better
use `ptrace' and then login will still have the file descriptor
pointing to /etc/spwd.db open and I can make it read the complete
shadow file.

> I haven't investigated this too far yet, but the idea of having the
> getpwent code clear each buffer it uses before freeing it may be practical
> and doesn't look too complex.  That shouldn't create too much overhead and
> could certainly benefit more than ftpd. 

Why don't make endpwent clear the area and make ftpd & c:o call it?

/assar