Protect yourself against future threats.
-----BEGIN PGP SIGNED MESSAGE-----
===========================================================================
AUSCERT External Security Bulletin Redistribution
ESB-2001.333 -- FreeBSD-SA-01:52.fragment
Denial of service using fragmented IPv4 packets
7 August 2001
===========================================================================
AusCERT Security Bulletin Summary
---------------------------------
Product: kernel
Vendor: FreeBSD
Operating System: FreeBSD 4.x prior to correction date
FreeBSD 3.x prior to correction date
BSD
Impact: Denial of Service
Access Required: Remote
- --------------------------BEGIN INCLUDED 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-----
- --------------------------END INCLUDED TEXT--------------------
You have received this e-mail bulletin as a result of your organisation's
registration with AusCERT. The mailing list you are subscribed to is
maintained within your organisation, so if you do not wish to continue
receiving these bulletins you should contact your local IT manager. If
you do not know who that is, please send an email to auscert@auscert.org.au
and we will forward your request to the appropriate person.
This security bulletin is provided as a service to AusCERT's members. As
AusCERT did not write the document quoted above, AusCERT has had no control
over its content. The decision to use any or all of this information is
the responsibility of each user or organisation, and should be done so in
accordance with site policies and procedures.
NOTE: This is only the original release of the security bulletin. It may
not be updated when updates to the original are made. If downloading at
a later date, it is recommended that the bulletin is retrieved directly
from the original authors to ensure that the information is still current.
Contact information for the authors of the original document is included
in the Security Bulletin above. If you have any questions or need further
information, please contact them directly.
Previous advisories and external security bulletins can be retrieved from:
http://www.auscert.org.au/Information/advisories.html
If you believe that your system has been compromised, contact AusCERT or
your representative in FIRST (Forum of Incident Response and Security
Teams).
Internet Email: auscert@auscert.org.au
Facsimile: (07) 3365 7031
Telephone: (07) 3365 4417 (International: +61 7 3365 4417)
AusCERT personnel answer during Queensland business hours
which are GMT+10:00 (AEST).
On call after hours for emergencies.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
Comment: ftp://ftp.auscert.org.au/pub/auscert/AUSCERT_PGP.key
iQCVAwUBO2/wXCh9+71yA2DNAQEtxwP6A85BjLv+ucrXOWn+kGTrHiCpXdqSkYRN
wnMAi+EtQ9Z0zIU4KLJvfsTR7Tl5JL1ADXoI5vtR5IBVvm7Img3MFbFuL0B1Cf51
vuzUdNdd1qwJ+65l9h2yRbufrEoaUuwo3ReDpdT+Ngv/SEPL0tbgWfkcwT8ggaSP
5cc2/38XsRQ=
=/r2F
-----END PGP SIGNATURE-----