From owner-freebsd-security Tue Jul 30 18:40:54 2002 Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 20C3437B400 for ; Tue, 30 Jul 2002 18:40:46 -0700 (PDT) Received: from localhost.neotext.ca (h24-70-64-200.ed.shawcable.net [24.70.64.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id C418A43E65 for ; Tue, 30 Jul 2002 18:40:44 -0700 (PDT) (envelope-from campbell@babayaga.neotext.ca) Received: from babayaga.neotext.ca (localhost.neotext.ca [127.0.0.1]) by localhost.neotext.ca (8.11.6/8.11.0) with ESMTP id g6V1f5u40958 for ; Tue, 30 Jul 2002 19:41:06 -0600 (MDT) (envelope-from campbell@babayaga.neotext.ca) From: "Duncan Patton a Campbell is Dhu" To: security@FreeBSD.ORG Subject: Re: FreeBSD Security Advisory FreeBSD-SA-02:23.stdio [REVISED] Date: Tue, 30 Jul 2002 19:41:05 -0600 Message-Id: <20020731014105.M64421@babayaga.neotext.ca> In-Reply-To: <200207301821.g6UIL5nc034058@freefall.freebsd.org> References: <200207301821.g6UIL5nc034058@freefall.freebsd.org> X-Mailer: Open WebMail 1.70 20020712 X-OriginatingIP: 127.0.0.1 (campbell) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Peculiar but true: The first time I fetched these patches (I got both) the stdio and stdio2 patches both had 804 octets in 'em: -rw-r--r-- 1 root wheel 804 Jul 29 21:26 stdio.patch.v1.2 -rw-r--r-- 1 root wheel 305 Jul 29 21:26 stdio.patch.v1.2.asc -rw-r--r-- 1 root wheel 804 Jul 29 21:26 stdio2.patch.v1.2 -rw-r--r-- 1 root wheel 305 Jul 29 21:26 stdio2.patch.v1.2.asc On the second go they differed: -rw------- 1 root wheel 3715 Jul 30 19:15 stdio.patch.v1.2 -rw------- 1 root wheel 305 Jul 30 19:15 stdio.patch.v1.2.asc -rw-r--r-- 1 root wheel 804 Jul 29 21:26 stdio2.patch.v1.2 -rw-r--r-- 1 root wheel 305 Jul 29 21:26 stdio2.patch.v1.2.asc Warning, warning, Will Robinson! Would anyone care to hazard a guess as to whether I've been rooted? Duncan Patton a Campbell is Duibh ;-) ---------- Original Message ----------- From: FreeBSD Security Advisories To: FreeBSD Security Advisories Sent: Tue, 30 Jul 2002 11:21:05 -0700 (PDT) Subject: FreeBSD Security Advisory FreeBSD-SA-02:23.stdio [REVISED] > -----BEGIN PGP SIGNED MESSAGE----- > > ============================================================================= > FreeBSD-SA-02:23.stdio > Security Advisory > The FreeBSD Project > > Topic: insecure handling of stdio file descriptors > > Category: core > Module: kernel > Announced: 2002-04-22 > Credits: Joost Pol , > Georgi Guninski > Affects: All releases of FreeBSD up to and > including 4.6-RELEASE > 4.6-STABLE prior to the correction date > Corrected: 2002-07-30 15:40:46 UTC (RELENG_4) > 2002-07-30 15:42:11 UTC (RELENG_4_6) > 2002-07-30 15:42:46 UTC (RELENG_4_5) > 2002-07-30 15:43:17 UTC (RELENG_4_4) > FreeBSD only: NO > > 0. Revision History > > v1.0 2002-04-22 Initial release > v1.1 2002-04-23 Patch and revision numbers updated > v1.2 2002-07-29 procfs issue; updated patch > > I. Background > > By convention, POSIX systems associate file > descriptors 0, 1, and 2 with standard input, standard > output, and standard error, respectively. Almost all > applications give these stdio file descriptors special > significance, such as writing error messages to > standard error (file descriptor 2). > > In new processes, all file descriptors are duplicated > from the parent process. Unless these descriptors are > marked close-on-exec, they retain their state during > an exec. > > All POSIX systems assign file descriptors in > sequential order, starting with the lowest unused file > descriptor. For example, if a newly exec'd process > has file descriptors 0 and 1 open, but file descriptor > 2 closed, and then opens a file, the new file > descriptor is guaranteed to be 2 (standard error). > > II. Problem Description > > Some programs are set-user-id or set-group-id, and > therefore run with increased privileges. If such a > program is started with some of the stdio file > descriptors closed, the program may open a file and > inadvertently associate it with standard input, > standard output, or standard error. The program may > then read data from or write data to the file > inappropriately. If the file is one that the user > would normally not have privileges to open, this may > result in an opportunity for privilege escalation. > > The original correction for this problem > (corresponding to the first revision of this advisory) > contained an error. Systems using procfs or linprocfs > could still be exploited. The dates for the original, > incomplete correction were: > > Corrected: 2002-04-21 13:06:45 UTC (RELENG_4) > 2002-04-21 13:08:57 UTC (RELENG_4_5) > 2002-04-21 13:10:51 UTC (RELENG_4_4) > > III. Impact > > Local users may gain superuser privileges. It is > known that the `keyinit' set-user-id program is > exploitable using this method. There may be other > programs that are exploitable. > > IV. Workaround > > [FreeBSD systems earlier than 4.5-RELEASE-p4 and 4.4- > RELEASE-p11] > > None. The set-user-id bit may be removed from > `keyinit' using the following command, but note that > there may be other programs that can be exploited. > > # chmod 0555 /usr/bin/keyinit > > [FreeBSD versions 4.5-RELEASE-p4 or later, 4.4-RELEASE- > p11 or later, > 4.6-RELEASE, and 4.6-STABLE] > > Unmount all instances of the procfs and linprocfs > filesystems using the umount(8) command: > > # umount -f -a -t procfs > # umount -f -a -t linprocfs > > V. Solution > > The kernel was modified to check file descriptors 0, 1, > and 2 when starting a set-user-ID or set-group-ID > executable. If any of these are not in use, they will > be redirected to /dev/null. > > 1) Upgrade your vulnerable system to 4.6-STABLE; or to > any of the RELENG_4_6 (4.6.1-RELEASE-p1), RELENG_4_5 > (4.5-RELEASE-p10), or RELENG_4_4 (4.4-RELEASE-p17) > security branches dated after the respective > correction dates. > > 2) To patch your present system: > > a) Download the relevant patch from the location below, > and verify the detached PGP signature using your PGP utility. > > [FreeBSD systems earlier than 4.5-RELEASE-p4 and 4.4- > RELEASE-p11] > > # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-02:23/stdio.patch.v1.2 > # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-02:23/stdio.patch.v1.2.asc > > [FreeBSD versions 4.5-RELEASE-p4 or later, 4.4-RELEASE- > p11 or later, > 4.6-RELEASE, and 4.6-STABLE] > > # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-02:23/stdio2.patch.v1.2 > # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-02:23/stdio2.patch.v1.2.asc > > b) Execute the following commands as root: > > # cd /usr/src > # patch < /path/to/patch > > c) Recompile your kernel as described in > http://www.freebsd.org/handbook/kernelconfig.html and > reboot the system. > > VI. Correction details > > The following list contains the revision numbers of > each file that was corrected in FreeBSD. > > Path > Revision Branch - -------------------------- > ----------------------------------------------- sys/sys/filedesc.h > RELENG_4 > 1.19.2.4 RELENG_4_6 > 1.19.2.4 RELENG_4_5 > 1.19.2.3.6.1 > RELENG_4_4 > 1.19.2.3.4.1 sys/kern/kern_exec.c RELENG_4 > > 1.107.2.15 RELENG_4_6 > 1.107.2.14.2.1 RELENG_4_5 > 1.107.2.13.2.2 > RELENG_4_4 > 1.107.2.8.2.3 sys/kern/kern_descrip.c RELENG_4 > 1.81.2.12 > RELENG_4_6 > 1.81.2.14 RELENG_4_5 > 1.81.2.9.2.2 RELENG_4_4 > 1.81.2.8.2.2 > sys/conf/newvers.sh RELENG_4_6 > 1.44.2.23.2.6 RELENG_4_5 > > 1.44.2.20.2.11 RELENG_4_4 > 1.44.2.17.2.16 - -------------------- > ----------------------------------------------------- > > VII. References > > PINE-CERT-20020401 > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.7 (FreeBSD) > > iQCVAwUBPUbXw1UuHi5z0oilAQFgKQP/eOnmHorw/4NVEAEKTQp4+X7Px9p1wUGq > 6OcLH5GuTbbwexd7KbCjbjzNZF7zgz1Qph2v7NQXb+W/ZaW2hEgcoURXkBomVxjl > 61oXu72P35bmgNo7GQ794v/WDHd8FymtBv0kyY/vuZqg6l99tTuwi2ryV1ZszVrh > w21lAbhkyQo= > =YGVw > -----END PGP SIGNATURE----- > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security-notifications" in > the body of the message ------- End of Original Message ------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message