Date: Mon, 14 Oct 1996 15:52:18 -0600 (MDT) From: Marc Slemko <marcs@znep.com> To: Guido van Rooij <guido@gvr.win.tue.nl> Cc: freebsd-security@freebsd.org Subject: Re: bin/1805: Bug in ftpd Message-ID: <Pine.BSF.3.95.961014150514.4318G-100000@alive.ampr.ab.ca> In-Reply-To: <199610142059.WAA02649@gvr.win.tue.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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: > > > > I'm not really happy with this fix as well, but it's better than nothing., > The reason being that if ftp wants to dump core, it should dump core. > If you prohibit this you'll never be able to debug any problems after > somethuing went wrong. What should be done is make sure the buffers containing > 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 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. There is definitely more than one user's password string being dumped. The FreeBSD boxes I have handy right now don't have many users, so I have only seen half a dozen or so (ie. the number of users) but on the BSD/OS box it was definitely more than a dozen passwords. Not a deadly flaw, especially since people should act as if the contents of their shadow password files are world readable anyway, but potentially quite serious if the wrong accounts are in there and the admin isn't running anything like crack. This is not just a problem with FreeBSD, but also BSD/OS 2.0.1 and possibly AIX (the box I tested on showed the problem of core dumping, but is using AFS so authentication works differently). NetBSD and OpenBSD are likely affected too. I haven't tested this on a -current box, but I am assuming the code will be the same since neither ftpd or the getpwent library have changed much. SunOS 4.x and 5.x don't seem vulnerable. It is also present in older (ie. before the current beta versions) releases of wuftpd. In current versions of wuftpd, it is avoided by having signal handlers installed and having the signal handler simply call exit(1). In older versions of wuftpd, the signal handlers were there but they called abort() so it dumped core anyway. If a solution within ftpd is required, I would suggest that either a compile time define (eg. DEBUG) to enable dumping core or a command line flag, with appropriate warnings, to allow dumping core may be a compromise between not dumping core and allowing debugging. It is arguable if it is a bug in ftpd or in the getpwent routines, but I would be tempted to say both.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.961014150514.4318G-100000>