From owner-freebsd-hackers Sat Oct 19 20:27:53 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA01100 for hackers-outgoing; Sat, 19 Oct 1996 20:27:53 -0700 (PDT) Received: from zygorthian-space-raiders.MIT.EDU (ZYGORTHIAN-SPACE-RAIDERS.MIT.EDU [18.70.0.61]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA01090 for ; Sat, 19 Oct 1996 20:27:46 -0700 (PDT) Received: (from mycroft@localhost) by zygorthian-space-raiders.MIT.EDU (8.7.4/8.6.11) id XAA25975; Sat, 19 Oct 1996 23:27:28 -0400 (EDT) To: tech-userlevel@NetBSD.ORG, freebsd-hackers@freefall.FreeBSD.org Subject: setuid, core dumps, ftpd, and DB From: mycroft@mit.edu (Charles M. Hannum) Date: 19 Oct 1996 23:27:17 -0400 Message-ID: Lines: 51 X-Mailer: Gnus v5.2.37/Emacs 19.30 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk There seems to be a lot of confusion about the security issues here, so I will give a quick summary. * Zeroing DB buffers is at best a partial solution to the security issues raised. It does not deal with stdio buffers or RPC buffers. It does not deal with temporary data areas used by such things as sorting routines. * There are probably a number of cases where a process can be sent a signal that would normally cause a core dump, while it still has sensitive data. A program using sensitive data should be aware of this and prevent itself from core dumping. However, there are cases where a process may not be able to know this, because a library may have external storage that it doesn't know about. * As an added check, in NetBSD, a process may not core dump if it has ever changed its IDs since (or during) the most recent exec; this is intended to insure that any data fetched by a set-id program is removed. However, this is *not* a complete solution in itself, because it's possible for a set-id program to call another one, which would not have this protection. (The set-id program could of course disable core dumping before calling the program, so it does have a way around this.) * In the particular case of ftpd, if you've logged in as a user other than root, then your saved, real, and effective uids do not match, so the previous check we used to use (ruid != svuid || ruid != euid) would catch this. So, unless you're logged in as root, you'd be hard pressed to get ftpd to core dump. * Although core dumps are written with mode 0600, this is not secure in all environments. In particular, it may be written out over NFS (and thus sent over the wire in cleartext), or it may be written out to AFS (for which the mode means more or less nothing, and which may also be snooped if encryption is not enabled). It seems to me that a general tainting algorithm for deciding when a program has sensitive data, and preventing core dumps during those times, is what we really need. Questions to consider: * Do you prevent core dumps if you've ever had any tainted data, or do you attempt to decide when you no longer have any? * If the latter, how? Always zero buffers (including partial zeroing of stdio buffers as you read from them!), create new interfaces to the libraries to inform them which data is secure, etc? Garbage collection? B-) I invite people to start a (sane) dialog on this issue.