From owner-freebsd-hackers Sat Oct 19 06:07:43 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA20282 for hackers-outgoing; Sat, 19 Oct 1996 06:07:43 -0700 (PDT) Received: from sovcom.kiae.su (sovcom.kiae.su [193.125.152.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id GAA20277 for ; Sat, 19 Oct 1996 06:07:39 -0700 (PDT) Received: by sovcom.kiae.su id AA28344 (5.65.kiae-1 ); Sat, 19 Oct 1996 16:05:40 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Sat, 19 Oct 96 16:05:40 +0300 Received: (from ache@localhost) by nagual.ru (8.7.6/8.7.3) id QAA00669; Sat, 19 Oct 1996 16:57:04 +0400 (MSD) Message-Id: <199610191257.QAA00669@nagual.ru> Subject: Re: cvs commit: src/lib/libc/db/hash hash_buf.c In-Reply-To: <199610190005.SAA28067@zeus.theos.com> from "Theo de Raadt" at "Oct 18, 96 06:05:09 pm" To: deraadt@theos.com (Theo de Raadt) Date: Sat, 19 Oct 1996 16:57:04 +0400 (MSD) Cc: hackers@freebsd.org From: "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" (Andrey A. Chernov) Organization: self X-Class: Fast X-Mailer: ELM [version 2.4ME+ PL28 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > well, that would be foolish. there are other issues which noone > outside of openbsd has thought of yet. we've found about 3 other > related holes, and i can definately say you should not back that > change out. It seems that you not follow this discussion well, so I repeat essential points for you: 1) Application can store its secure data ANYWHERE, db, stack, etc. So, cover only one area gains nothing. 2) Any attempts to automatically erase secure data ANYWHERE leads to performance degradation for applications which not want it. 3) Dropping core isn't a point, once SUID programs must not drop non-superuser readable cores. 4) Applications/functions which want to erase its secure data in the memory (if it care about physical memory browsing) must do it by yourself. 5) Getpw*() family can be treated as example of 4), so it can do it, but definitely NOT generic db close. 6) So, some erasing function must be added to generic db interface which allows endpwent() to erase its memory when called directly. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -- Andrey A. Chernov http://www.nagual.ru/~ache/