FreeBSD Security Advisories
2001-Aug-06 15:15 UTC
FreeBSD Security Advisory FreeBSD-SA-01:52.fragment
-----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.
<URL:http://www.securityfocus.com/vdb/bottom.html?vid=2799>
<URL:ftp://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2001-006.txt.asc>
-----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