From owner-freebsd-announce Mon Aug 6 14:47:22 2001 Delivered-To: freebsd-announce@freebsd.org Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id EA99237B409; Mon, 6 Aug 2001 14:47:09 -0700 (PDT) (envelope-from security-advisories@FreeBSD.org) Received: (from kris@localhost) by freefall.freebsd.org (8.11.4/8.11.4) id f76Ll9A01632; Mon, 6 Aug 2001 14:47:09 -0700 (PDT) (envelope-from security-advisories@FreeBSD.org) Date: Mon, 6 Aug 2001 14:47:09 -0700 (PDT) Message-Id: <200108062147.f76Ll9A01632@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: kris set sender to security-advisories@FreeBSD.org using -f From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-01:42.signal [REVISED] Reply-To: security-advisories@FreeBSD.org Sender: owner-freebsd-announce@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- ============================================================================= FreeBSD-SA-01:42 Security Advisory FreeBSD, Inc. Topic: signal handling during exec may allow local root compromise Category: core Module: kernel Announced: 2001-07-10 Revised: 2001-08-06 Credits: Georgi Guninski Affects: All released versions of FreeBSD 4.x, FreeBSD 4.3-STABLE prior to the correction date. Corrected: 2001-07-09 FreeBSD only: Yes 0. Revision History 2001-07-10 v1.0 Initial release 2001-08-06 v1.1 Binary upgrade package available I. Background When a process forks, it inherits the parent's signals. When the process execs, the kernel clears the signal handlers because they are not valid in the new address space. II. Problem Description A flaw exists in FreeBSD signal handler clearing that would allow for some signal handlers to remain in effect after the exec. Most of the signals were cleared, but some signal hanlders were not. This allowed an attacker to execute arbitrary code in the context of a setuid binary. All versions of 4.x prior to the correction date including and 4.3-RELEASE are vulnerable to this problem. The problem has been corrected by copying the inherited signal handlers and resetting the signals instead of sharing the signal handlers. III. Impact Local users may be able to gain increased privileges on the local system. IV. Workaround Do not allow untrusted users to gain access to the local system. V. Solution One of the following: 1) Upgrade your vulnerable FreeBSD system to 4.3-STABLE after the correction date. 2) To patch your present system: download the relevant patch from the below location, and execute the following commands as root: [FreeBSD 4.1, 4.2, and 4.3 base systems] This patch has been verified to apply to FreeBSD 4.1, 4.2, and 4.3 only. It may or may not apply to older releases. # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:42/signal-4.3.patch # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:42/signal-4.3.patch.asc Verify the detached PGP signature using your PGP utility. # cd /usr/src/sys/kern # patch -p < /path/to/patch [ Recompile your kernel as described in http://www.freebsd.org/handbook/kernelconfig.html and reboot the system ] 3) FreeBSD 4.3-RELEASE systems: An experimental upgrade package is available for users who wish to provide testing and feedback on the binary upgrade process. This package may be installed on FreeBSD 4.3-RELEASE systems only, and is intended for use on systems for which source patching is not practical or convenient. If you use the upgrade package, feedback (positive or negative) to security-officer@FreeBSD.org is requested so we can improve the process for future advisories. Since this vulnerability involves the FreeBSD kernel which is often locally customized on installed systems, a universal binary upgrade package is not feasible. This package includes a patched version of the GENERIC kernel which should be suitable for use on many systems. Systems requiring a customized kernel must use an alternative solution. During the installation procedure, backup copies are made of the files which are replaced by the package. These backup copies will be reinstalled if the package is removed, reverting the system to a pre-patched state. # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/packages/SA-01:42/security-patch-signal-01.42.tgz # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/packages/SA-01:42/security-patch-signal-01.42.tgz.asc Verify the detached PGP signature using your PGP utility. # pkg_add security-patch-signal-01.42.tgz The new kernel is named /kernel.GENERIC to avoid conflict with the default kernel name (``/kernel''). To cause the system to boot automatically with the new kernel, add the following line to /boot/loader.conf: kernel="/kernel.GENERIC" and reboot the system to load the new kernel. The old kernel is still available and can be manually loaded in the boot loader in case of problems. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iQCVAwUBO28Pu1UuHi5z0oilAQHjeAQAmND4sSS6k1RHCz+uHSQb6hrX6vkKDr2M /9EMf/S90WFwVfIi7ifEgeY3U6XJpRd2Bdx1rCPOCMdSYkehd+WqVM8ZSgHkbpAL vrwS8KHrcC/G7KhCGzH5c6PjZYISdHXi4hWB9aV11zmmJZk3wL5GlIAaH8Dik403 w2SjxgHHM8w= =qVIE -----END PGP SIGNATURE----- This is the moderated mailing list freebsd-announce. The list contains announcements of new FreeBSD capabilities, important events and project milestones. See also the FreeBSD Web pages at http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-announce" in the body of the message From owner-freebsd-announce Mon Aug 6 15:15:28 2001 Delivered-To: freebsd-announce@freebsd.org Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 3FDC337B40A; Mon, 6 Aug 2001 15:15:06 -0700 (PDT) (envelope-from security-advisories@FreeBSD.org) Received: (from kris@localhost) by freefall.freebsd.org (8.11.4/8.11.4) id f76MF6N06597; Mon, 6 Aug 2001 15:15:06 -0700 (PDT) (envelope-from security-advisories@FreeBSD.org) Date: Mon, 6 Aug 2001 15:15:06 -0700 (PDT) Message-Id: <200108062215.f76MF6N06597@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: kris set sender to security-advisories@FreeBSD.org using -f From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-01:52.fragment Reply-To: security-advisories@FreeBSD.org Sender: owner-freebsd-announce@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- ============================================================================= FreeBSD-SA-01:52 Security Advisory FreeBSD, Inc. Topic: Denial of service using fragmented IPv4 packets Category: kernel Announced: 2001-08-06 Credits: "James Thomas" via NetBSD Affects: All releases of FreeBSD 3.x, 4.x prior to 4.4, FreeBSD 4.3-STABLE prior to the correction date Corrected: 2001-06-16 23:48:04 UTC (FreeBSD 4.3-STABLE) 2001-08-05 23:08:26 UTC (RELENG_4_3) 2001-08-06 09:20:57 UTC (FreeBSD 3.5.1-STABLE) FreeBSD only: NO I. Background The IP protocol allows datagrams (``packets'') to be fragmented in transit to allow transportation by lower layers with a smaller frame size than the desired IP datagram size. The fragments are collected and reassembled on the destination system. II. Problem Description Remote users may be able to prevent a FreeBSD system from communicating with other systems on the network by transmitting large numbers of fragmented IPv4 datagrams. For the attack to be effective, the attacker must have a high-bandwidth connection to the target system (for example, connected via a local network or over a fast remote network connection). IP datagram fragments destined to the target system will be queued for 30 seconds, to allow fragmented datagrams to be reassembled. Until recently, there was no upper limit in the number of reassembly queues. Therefore, a malicious party may be able to transmit a lot of bogus fragmented datagrams (with different IPv4 identification field) and cause the target system to exhaust its mbuf pool, preventing further network traffic processing or generation while the starvation condition continues. To solve this problem an upper limit was placed on the number of fragment reassembly queues. This value is tunable at runtime using the net.inet.ip.maxfragpackets sysctl: the sysctl is set to a default value at system startup but may be tuned up or down depending on the role of the system (e.g. if the system is a busy server which typically receives a lot of fragmented datagrams, you may want to set the value higher). The old system behaviour of an unlimited number of reassembly queues can be obtained by setting this sysctl to a negative value. Note however that attackers are still able to prevent legitimate fragmented IPv4 traffic from being reassembled by flooding the system with bogus fragmented datagrams and keeping the reassembly queues full. Unfragmented IPv4 communications will be unaffected by such an attack when this variable is set. All versions of FreeBSD 3.x and 4.x prior to the correction date including 3.5.1-RELEASE and 4.3-RELEASE are vulnerable to this problem, although exploitation is mitigated by the need for high-bandwidth access to the target machine. III. Impact IPv4-connected systems can be put into a resource-starved state from which they are unable to send or receive network traffic by the constant bombardment of the system by fragmented datagrams. IV. Workaround A possible workaround for systems which are under active attack is to increase the value of the NMBCLUSTERS kernel option on attacked machines and rebuild the kernel as described in the following URL: http://www.freebsd.org/handbook/kernelconfig.html This may provide a temporary solution until the patch can be applied: normally, it is the cluster mbufs which are exhausted by this attack. By setting NMBCLUSTERS to a higher value, you may be able to prevent the mbuf memory pool from being starved. VI. Solution One of the following: 1) Upgrade your vulnerable FreeBSD system to 4.3-STABLE or the RELENG_4_3 security-fix branch dated after the correction date. 2) To patch your present system: download the relevant patch from the below location, and execute the following commands as root: [FreeBSD 4.x] This patch has been verified to apply to FreeBSD 4.2-RELEASE and 4.3-RELEASE systems. It may or may not apply to older, unsupported releases. # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:52/frag-4.x.patch # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:52/frag-4.x.patch.asc [FreeBSD 3.x] This patch has been verified to apply to FreeBSD 3.5.1-RELEASE systems. It may or may not apply to older, unsupported releases. # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:52/frag-3.x.patch # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:52/frag-3.x.patch.asc Verify the detached PGP signature using your PGP utility. # cd /usr/src/ # patch -p < /path/to/patch Rebuild the kernel as described in the following URL: http://www.freebsd.org/handbook/kernelconfig.html 3) FreeBSD 4.3-RELEASE systems: An experimental upgrade package is available for users who wish to provide testing and feedback on the binary upgrade process. This package may be installed on FreeBSD 4.3-RELEASE systems only, and is intended for use on systems for which source patching is not practical or convenient. If you use the upgrade package, feedback (positive or negative) to security-officer@FreeBSD.org is requested so we can improve the process for future advisories. Since this vulnerability involves the FreeBSD kernel which is often locally customized on installed systems, a universal binary upgrade package is not feasible. This package includes a patched version of the GENERIC kernel which should be suitable for use on many systems. Systems requiring a customized kernel must use an alternative solution. During the installation procedure, backup copies are made of the files which are replaced by the package. These backup copies will be reinstalled if the package is removed, reverting the system to a pre-patched state. # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/packages/SA-01:52/security-patch-fragment-01.52.tgz # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/packages/SA-01:52/security-patch-fragment-01.52.tgz.asc Verify the detached PGP signature using your PGP utility. # pkg_add security-patch-fragment-01.52.tgz The new kernel is named /kernel.GENERIC to avoid conflict with the default kernel name (``/kernel''). To cause the system to boot automatically with the new kernel, add the following line to /boot/loader.conf: kernel="/kernel.GENERIC" and reboot the system to load the new kernel. The old kernel is still available and can be manually loaded in the boot loader in case of problems. VII. Credits/References NetBSD wrote the original advisory from which large portions of this advisory was taken. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iQCVAwUBO28VK1UuHi5z0oilAQHU9AQAor9fi3Lp5Xtny/zPJpVcX4+96WvsqX4e j7xtydSKwbZg78AxCYzD53FnZ/Tmb0XCf6if0L+k4QFzBsmavauB2hoszJMuT1x0 WdcQmBvzIy5Oibffv88Kev760K7icdkskWYTLPJMxmP0dec9NZBLkTcR6udMyy2u JbK9HknLMiE= =8PO/ -----END PGP SIGNATURE----- This is the moderated mailing list freebsd-announce. The list contains announcements of new FreeBSD capabilities, important events and project milestones. See also the FreeBSD Web pages at http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-announce" in the body of the message