From owner-freebsd-security Wed Feb 19 05:21:06 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA22006 for security-outgoing; Wed, 19 Feb 1997 05:21:06 -0800 (PST) Received: from magrathea.chance.ru (root@magrathea.chance.ru [194.58.86.1]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id FAA21983 for ; Wed, 19 Feb 1997 05:20:57 -0800 (PST) Received: (from caseq@localhost) by magrathea.chance.ru (8.6.12/8.6.12) id QAA11111; Wed, 19 Feb 1997 16:20:07 +0300 From: Andrew Kosyakov Message-Id: <199702191320.QAA11111@magrathea.chance.ru> Subject: Re: Coredumps and setuids .. interesting.. To: dg@root.com Date: Wed, 19 Feb 1997 16:20:07 +0300 (MSK) Cc: rbezuide@oskar.nanoteq.co.za, jas@flyingfox.COM, security@freebsd.org In-Reply-To: <199702191254.EAA12072@root.com> from "David Greenman" at Feb 19, 97 04:54:41 am Organization: Chance Publishing House X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Quoting David Greenman: > >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 > No, this isn't a good solution. It only deals with one type of sensitive > data (encrypted passwords), and doesn't really "solve" the problem (e.g. Well, I'm not proclaiming this to be the panacea, and, in fact, this often (but not always) solves the problem not only for password database, but for any data stored in 'hash' dbm format. And, certainly, it _helped_ against *fptd/rlogin/screen vulnerabilities and didn't broke anything except from one of my friend's poorly written program which relied on data being in core after data base's been closed :-) > you could still get it to coredump prior to it having a chance to zero > everything out). Why, it would be unwise of it to close data base before dropping root privileges (and in this case it will be impossible at all), and I won't be able to send any signal to it unless it drops privileges. The case when it dumps core due to some memory fault still remains, but it will probably be serious hole itself. And I think we'll agree on that BOTH measures should be taken. > The only "correct" solution is to not allow processes with potentially > sensitive data (setuid, setgid) to coredump in the first place. You should also remember processes started as root and used set*id() to drop privileges, such as ftpd. -- Sincerely yours /&rew *** Andrew V. Kosyakov, Chance Publishing House, System Administrator caseq@chance.ru, 2:5030/31@Fidonet.Org, +7(812)210-8046 PGP key fingerprint: BA A8 48 20 E4 AE 9C 52 C5 5F C3 B8 1E 67 2C BF