Date: Tue, 7 Aug 2001 20:16:40 +0200 From: "Thomas Beer" <tom@analogon.com> To: <questions@FreeBSD.org> Subject: Fw: FreeBSD Security Advisory FreeBSD-SA-01:52.fragment Message-ID: <015901c11f6d$1af8e4e0$0901a8c0@system>
next in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, can anyone confirm, that this pgp sign advisory is valid? Thanks Tom > >*** PGP Signature Status: bad ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >*** Signer: FreeBSD Security Officer <security-officer@freebsd.org> >*** Signed: 07.08.01 01:07:38 >*** Verified: 07.08.01 20:15:15 >*** BEGIN PGP VERIFIED 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-fra >gment-01.52.tgz # fetch >ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/packages/SA-01:52/security-patch-fra >gment-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. > ><URL:http://www.securityfocus.com/vdb/bottom.html?vid=2799>; ><URL:ftp://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2001-006. >txt.asc> > > > >*** END PGP VERIFIED MESSAGE *** > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-security" in the body of the message > > -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.2 for non-commercial use <http://www.pgp.com>; iQA/AwUBO3Aid26Mn6deTS6qEQKtowCfWHIXCOigH+XVej4/P1qSdcuQpsMAoOOv cb+ydQccjqqh94gW3eX+IRo1 =NPZl -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?015901c11f6d$1af8e4e0$0901a8c0>