Date: Mon, 14 Oct 1996 18:37:25 -0600 (MDT) From: Marc Slemko <marcs@znep.com> To: Assar Westerlund <assar@sics.se> Cc: Guido van Rooij <guido@gvr.win.tue.nl>, freebsd-security@FreeBSD.org Subject: Re: bin/1805: Bug in ftpd Message-ID: <Pine.BSF.3.95.961014170102.4318H-100000@alive.ampr.ab.ca> In-Reply-To: <5lvicd6ufk.fsf@assaris.sics.se>
next in thread | previous in thread | raw e-mail | index | archive | help
On 15 Oct 1996, Assar Westerlund wrote:
> > 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.
You are right. I just checked, and I can make login dump core in the same
way and reveal similar information. Haven't tried stealing the file
descriptor since that takes effort, but it certainly looks like it could
be possible.
>
> > 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?
That sounds like the best idea. The problem is more widespread than I
realized. Note that getpwent calls a bunch of NIS routines; they have to
be checked to see if they leave anything messy around. I think some of
the buffers we want to zero are from the DB routines, which could make it
even messier if the memory is allocated inside the DB routines and not as
a structure in getpwent.
What other information could ftpd (or login, etc.) have around other that
information from the getpwent that we don't want non-root users to see? I
still think that it is the responsibility of any process which starts
running as root then drops to the user to be sure not to leave any
potentially bad data in memory. In practice, however, that isn't always
practical, and I think the getpwent routines are of a nature that they
should be designed to not leave anything dangerous behind after an
endpwent.
So it looks like endpwent needs to be fixed up to clean up better after
itself and all programs that start as root and end up setuid to a user
need to be checked to be sure that they call endpwent after any getpwent
routines they call and before they setuid to the user.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.961014170102.4318H-100000>