From owner-freebsd-security Sun Aug 10 12:17:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA08032 for security-outgoing; Sun, 10 Aug 1997 12:17:26 -0700 (PDT) Received: from xkis.kis.ru (dv@xkis.kis.ru [195.98.32.200]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA08023 for ; Sun, 10 Aug 1997 12:17:17 -0700 (PDT) Received: from localhost (dv@localhost) by xkis.kis.ru (8.8.5/8.8.5) with SMTP id XAA01848 for ; Sun, 10 Aug 1997 23:16:57 +0400 (MSD) Date: Sun, 10 Aug 1997 23:16:57 +0400 (MSD) From: Dmitry Valdov To: freebsd-security@freebsd.org Subject: procfs hole (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello! Is There any fixes for it? ---------- Forwarded message ---------- Date: Sun, 10 Aug 1997 05:37:40 -0400 From: Brian Mitchell To: BUGTRAQ@NETSPACE.ORG Subject: procfs hole There is a major hole in procfs under FreeBSD 2.2.1 (2.1 is not affected, I have not tested 3.x but I believe it to be vulnerable as well) along with OpenBSD (not tested by me, but by someone else -- believe it was 2.1-RELEASE although obsd doesnt mount procfs by default like freebsd does). The problem is all proc/#/mem access is controlled by the permissions on the file. This means you can fork() open the childs mem device and then have the child execute a setuid executable. Once this is done, you can modify the setuid executables memory -- even segments that are supposed to be nonwritable can be modified. Enclosed is a simple exploit tested under FreeBSD 2.2.1 -- beware, this exploit is slow because it searches memory for a specific signature. Oh, you need to change your shell to a borneish shell too, since csh/tcsh will not work when euid != ruid (unless passed a -b script argument). BSDI is also believed to be vulnerable. Unfortunately, not only is procfs not mounted, it is not even in the GENERIC kernel. [exploit skipped] Dmitry.