From owner-freebsd-hackers  Thu Oct 17 12:12:33 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id MAA22646
          for hackers-outgoing; Thu, 17 Oct 1996 12:12:33 -0700 (PDT)
Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA22639;
          Thu, 17 Oct 1996 12:12:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.7.5/8.6.12) with SMTP id MAA06276; Thu, 17 Oct 1996 12:00:53 -0700 (PDT)
Message-Id: <199610171900.MAA06276@lestat.nas.nasa.gov>
X-Authentication-Warning: lestat.nas.nasa.gov: Host localhost [127.0.0.1] didn't use HELO protocol
To: Poul-Henning Kamp <phk@critter.tfs.com>
Cc: Guido van Rooij <guido@freebsd.org>, freebsd-hackers@freebsd.org,
        tech-userlevel@netbsd.org
Subject: Re: cvs commit: src/lib/libc/db/hash hash_buf.c 
Reply-To: Jason Thorpe <thorpej@nas.nasa.gov>
From: Jason Thorpe <thorpej@nas.nasa.gov>
Date: Thu, 17 Oct 1996 12:00:53 -0700
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

[ FYI, brought this discussion into more apropos venues... ]

On Thu, 17 Oct 1996 20:41:14 +0200 
 Poul-Henning Kamp <phk@critter.tfs.com> wrote:

 > >  Modified:    lib/libc/db/hash  hash_buf.c
 > >  Log:
 > >  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
 > 
 > Isn't this a pezzimization of rank ?  I mean there are many uses of this
 > that do not need this...

I sort of question the value of this change, myself.  Consider:

	a) If the encrypted strings are in the buffers, the
	   executable is running with euid == 0.

	b) Under NetBSD, if ruid != euid (i.e. Joe User running
	   a setuid 0 program), a core will not be dumped.

	c) Under NetBSD, the permissions on core files are
	   600, owned by the euid of the process.

So, given (b), a program run by Joe User, with entrypted strings
in the buffer, will not drop a core file.

Given (c), if the program is run by root, and it drops a core file,
only root can read it.

bzero'ing a hash buffer is not a complete solution to the problem,
since the process may contain other potentially sensitive data
in its address space.  What you really want to do is protect
the cores.

Looking at the FreeBSD kern_sig.c:coredump(), it does do some uid
sanity checking, but NetBSD added some additional checks in revision
1.55 ... you might want to peek at the current NetBSD sys/kern/kern_sig.c

Ciao.

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                               Home: 408.866.1912
NAS: M/S 258-6                                          Work: 415.604.0935
Moffett Field, CA 94035                                Pager: 415.428.6939