From owner-freebsd-hackers Fri Oct 18 18:23:28 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA08128 for hackers-outgoing; Fri, 18 Oct 1996 18:23:28 -0700 (PDT) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA08122 for ; Fri, 18 Oct 1996 18:23:20 -0700 (PDT) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.7.5/8.7.3) with UUCP id TAA13497; Fri, 18 Oct 1996 19:23:01 -0600 (MDT) Received: from localhost (marcs@localhost) by alive.ampr.ab.ca (8.7.5/8.7.3) with SMTP id TAA03989; Fri, 18 Oct 1996 19:18:55 -0600 (MDT) Date: Fri, 18 Oct 1996 19:18:49 -0600 (MDT) From: Marc Slemko X-Sender: marcs@alive.ampr.ab.ca To: Jason Thorpe cc: freebsd-hackers@freebsd.org Subject: Re: cvs commit: src/lib/libc/db/hash hash_buf.c In-Reply-To: <199610181737.KAA24797@lestat.nas.nasa.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 18 Oct 1996, Jason Thorpe wrote: > On Fri, 18 Oct 1996 11:56:57 -0500 (CDT) > Karl Denninger wrote: > > > 2) Any process which starts with the SUID or SGID bit on must > > internally decline to dump core (regardless of ulimit settings) at > > all times -- both while SUID and *IF SUID IS REVOKED BY THE JOB*. > > The program doens't have to do this... the _kernel_ should (and, under > NetBSD, does); see coredump() in kern_sig.c. The following change was hidden away in a bigger one committed to FreeBSD-current on 1996/03/02 which seems to do the same as the NetBSD code. It appears like the problem can't be exploited in -current via any method mentioned so far in this thread. So, if we can't or don't want to find an acceptable way to clear the memory used for the buffers, I would suggest the below change from -current should be commited to -stable. I think all the other bits are in stable (ie. access via procfs, can't use ptrace on a process that has done a setuid unless you are root), although there may be a couple of fixes to the procfs restictions that aren't in -stable. If anyone can find any ways to exploit the problem under -stable if this change is made, please bring them up. *** kern_sig.c 1996/01/31 12:44:13 1.18 --- kern_sig.c 1996/03/02 19:38:09 1.19 *************** *** 1204,1210 **** --- 1200,1212 ---- int error, error1; char name[MAXCOMLEN+6]; /* progname.core */ + /* + * If we are setuid/setgid, or if we've changed uid's in the past, + * we may be holding privileged information. We must not core! + */ if (pcred->p_svuid != pcred->p_ruid || pcred->p_svgid != pcred->p_rgid) + return (EFAULT); + if (p->p_flag & P_SUGID) return (EFAULT); if (ctob(UPAGES + vm->vm_dsize + vm->vm_ssize) >= p->p_rlimit[RLIMIT_CORE].rlim_cur)