From owner-freebsd-security Wed Feb 19 04:54:21 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA21045 for security-outgoing; Wed, 19 Feb 1997 04:54:21 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA21039 for ; Wed, 19 Feb 1997 04:54:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.8.5/8.6.5) with SMTP id EAA12072; Wed, 19 Feb 1997 04:54:41 -0800 (PST) Message-Id: <199702191254.EAA12072@root.com> X-Authentication-Warning: implode.root.com: localhost [127.0.0.1] didn't use HELO protocol To: Andrew Kosyakov cc: rbezuide@oskar.nanoteq.co.za (Reinier Bezuidenhout), jas@flyingfox.COM, security@freebsd.org Subject: Re: Coredumps and setuids .. interesting.. In-reply-to: Your message of "Wed, 19 Feb 1997 15:34:56 +0300." <199702191234.PAA10870@magrathea.chance.ru> From: David Greenman Reply-To: dg@root.com Date: Wed, 19 Feb 1997 04:54:41 -0800 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >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/): 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. you could still get it to coredump prior to it having a chance to zero everything out). The only "correct" solution is to not allow processes with potentially sensitive data (setuid, setgid) to coredump in the first place. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project