From owner-freebsd-security Sun Aug 3 11:21:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA06639 for security-outgoing; Sun, 3 Aug 1997 11:21:45 -0700 (PDT) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id LAA06622 for ; Sun, 3 Aug 1997 11:21:39 -0700 (PDT) Received: (from sef@localhost) by kithrup.com (8.6.8/8.6.6) id LAA18374 for security@freebsd.org; Sun, 3 Aug 1997 11:21:38 -0700 Date: Sun, 3 Aug 1997 11:21:38 -0700 From: Sean Eric Fagan Message-Id: <199708031821.LAA18374@kithrup.com> To: security@freebsd.org Subject: Proposed alternate patch for the rfork vulnerability Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I haven't looked at the rfork code extensively... I should. However, something similar to the following should be done for every shared resource that might be inhereted across a fork. (However, what are those? Looking at /sys/sys/unistd.h, it doesn't look like we actually implement anything other than shared VM [which is hosed across an exec anyway], no wait on child [which isn't relevent to this], and the fd table copying and zeroing... and that's what comes into play across an exec... So maybe this is all that should be necessary.) I haven't extensively tested this; I ran the included program, and I am currently up multiuser with my patched kernel. *** kern_exec.c.~1~ Sat Nov 9 02:42:28 1996 --- kern_exec.c Sun Aug 3 11:14:06 1997 *************** *** 325,330 **** --- 325,338 ---- vrele(ndp->ni_vp); FREE(ndp->ni_cnd.cn_pnbuf, M_NAMEI); + if (p->p_fd->fd_refcnt > 1) { + struct filedesc *tmp; + + tmp = fdcopy(p); + fdfree(p); + p->p_fd = tmp; + } + return (0); exec_fail_dealloc: