Subject: Re: cvs commit: src/lib/libc/db/hash hash_buf.c
To: John Polstra <jdp@polstra.com>
From: Karl Denninger <karl@Mcs.Net>
List: tech-userlevel
Date: 10/18/1996 00:21:38
> 
> > 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!