3571e53040
patches for easier mirroring, to eliminate a special copy, to make www.freebsd.org/security a full copy of security.freebsd.org and be eventually be the same. For now files are just sitting there. The symlinks are missing. Discussed on: www (repository location) Discussed with: simon (so)
177 lines
7 KiB
Text
177 lines
7 KiB
Text
-----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-----
|