From owner-freebsd-hackers Thu Oct 17 22:22:28 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA25583 for hackers-outgoing; Thu, 17 Oct 1996 22:22:28 -0700 (PDT) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA25578 for ; Thu, 17 Oct 1996 22:22:25 -0700 (PDT) Received: from mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.0/8.8.Beta.3) with SMTP id AAA27295; Fri, 18 Oct 1996 00:21:47 -0500 (CDT) Received: by mailbox.mcs.com (/\==/\ Smail3.1.28.1 #28.15) id ; Fri, 18 Oct 96 00:21 CDT Received: (from karl@localhost) by Jupiter.Mcs.Net (8.8.Beta.6/8.8.Beta.3) id AAA08257; Fri, 18 Oct 1996 00:21:39 -0500 (CDT) From: Karl Denninger Message-Id: <199610180521.AAA08257@Jupiter.Mcs.Net> Subject: Re: cvs commit: src/lib/libc/db/hash hash_buf.c To: jdp@polstra.com (John Polstra) Date: Fri, 18 Oct 1996 00:21:38 -0500 (CDT) Cc: ache@nagual.ru, guido@gvr.win.tue.nl, thorpej@nas.nasa.gov, phk@critter.tfs.com, freebsd-hackers@freebsd.org, tech-userlevel@netbsd.org In-Reply-To: <199610180459.VAA06725@austin.polstra.com> from "John Polstra" at Oct 17, 96 09:59:25 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > I consider it as a bad move too and performance degradation. > > Why only DB? Why you don't automatically clear stack too? :-) > > > > Passwords can be stored anywhere in the application, > > and it is per-application task to clear sensetive data anywhere. > > > > Please, back out this change. > > I agree. This change should definitely be backed out. > -- > John Polstra jdp@polstra.com > John D. Polstra & Co., Inc. Seattle, Washington USA > "Self-knowledge is always bad news." -- John Barth I disagree. The problem is that the callee (ie: ftpd) CAN'T GET TO THE STRUCTURE TO TAKE CARE OF IT. If there was a separate "destroy-data" call, that would be ok. But there isn't, and as such the ONLY way to have any security in these dbm routines is to have the system enforce it. Forcing ANYTHING that touches authentication to refuse to dump core is not the answer. Yet that is the only answer that you leave available. Worse, that doesn't even BEGIN to address the problmes that come about if you can ptrace() the process -- which, for something like this, is a REAL problem. You MUST be able to *know* that all privileged data has been nuked BEFORE you relinquish privileged operation. This isn't an option folks -- its a REQUIREMENT for security reasons. Figure it out. ftpd is not the only affected program here; just the most commonly known and exploited. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1 from $600 monthly; speeds to DS-3 available | 23 Chicagoland Prefixes, 13 ISDN, much more Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | Home of Chicago's only FULL Clarinet feed!