-----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-----