From owner-freebsd-security Wed Feb 19 13:35:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA20473 for security-outgoing; Wed, 19 Feb 1997 13:35:26 -0800 (PST) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA20466 for ; Wed, 19 Feb 1997 13:35:20 -0800 (PST) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.5/8.7.3) with UUCP id OAA20339; Wed, 19 Feb 1997 14:34:48 -0700 (MST) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id OAA01080; Wed, 19 Feb 1997 14:32:14 -0700 (MST) Date: Wed, 19 Feb 1997 14:32:13 -0700 (MST) From: Marc Slemko To: Andrew Kosyakov cc: security@freebsd.org Subject: Re: Coredumps and setuids .. interesting.. In-Reply-To: <199702191234.PAA10870@magrathea.chance.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 19 Feb 1997, Andrew Kosyakov wrote: > Quoting Reinier Bezuidenhout: > > > > to being killed in a way that would cause a core dump. Everyone prior to you > > > who has looked at the resulting core file (me included) has found that it > > > contained only the encrypted password for the user's own account, and not > > > any others. I'm rather surprised that you are saying that it contains other > > > users' encrypted passwords... > > and in there are ALL the users and their encrypted passwords, I can > > mail it ... but would rather not :) ... but seeing that 2.1.7 > Perhaps, many people fixed their libc since that similar case with wu-ftpd. > The solution is to patch dbm code the zero out all memory being free()'d, so > that when password database is closed by endpwent() called from some > getpwname(), all passwords (except the one being returned) are erased from > memory. The following changes were suggested by someone from OpenBSD project, > but still work great for FreeBSD (the file in question is in > /usr/src/lib/libc/db/hash/): > > > --- hash_buf.c.old Tue Oct 15 14:24:48 1996 > +++ hash_buf.c Tue Oct 15 14:24:13 1996 > @@ -324,7 +324,10 @@ > /* Check if we are freeing stuff */ > if (do_free) { > if (bp->page) > + { > + memset(bp->page,0,hashp->BSIZE); > free(bp->page); > + } > BUF_REMOVE(bp); > free(bp); > bp = LRU; > David has already responded about why it isn't the best solution, but please check the list archives archives for previous discussion on the same issue. BTDT: ---------------------------- revision 1.1.1.1.6.4 date: 1996/10/18 19:57:28; author: guido; state: Exp; lines: +1 -3 Backout bzero patch. ---------------------------- revision 1.1.1.1.6.3 date: 1996/10/17 18:27:58; author: guido; state: Exp; lines: +3 -1 When freeing buffers in the db routines, also zeroize them This should solve the bug where a coredumping ftpd reveals encrypted passwords. Obtained from: OpenBSD ---------------------------- It was decided this was the wrong fix. I agree. Warner's suggestion of adding to the API to allow a process to specify if they want it is fine, but non-portable and only solves very specific problems; ie. the process has to know to do it. I'm not sure it is worth it since you have to fix the problem some other way anyway for all the other programs. OTOH, being paranoid is good except when it isn't and I don't see a huge thing against Warner's suggestion. It may well be possible to find ways other than core dumps to get access to the memory image through bugs in ftpd.