OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: security-officernetbsd.org
Date: Wed May 30 2001 - 01:23:26 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    -----BEGIN PGP SIGNED MESSAGE-----

                     NetBSD Security Advisory 2001-006
                     =================================

    Topic: Denial of service using bogus fragmented IPv4 packets
    Version: NetBSD 1.4, 1.5, -current
    Severity: Network-connected systems can be crashed remotely
    Fixed: NetBSD-current: April 17, 2001 (1.5U)
                    NetBSD-1.5 branch: April 24, 2001 (1.5.1 will include the fix)
                    NetBSD-1.4 branch: (not yet available)

    Abstract
    ========

    Malicious parties may be able to prevent a NetBSD node from
    communicating with other nodes by transmitting a lot of bogus
    fragmented IPv4 packets.

    For the attack to be effective, the attacker needs to have good
    network connectivity to the victim node (like logged onto the victim
    machine itself, connected by a fat LAN, or whatever).

    There are exploits for this problem available on the Internet.
    However, the attack is timing dependent and the attack is not
    always successful.

    Technical Details
    =================

    In the IPv4 input path (sys/netinet/ip_input.c), there's code to
    reassemble fragmented IPv4 datagrams. Datagram fragments destined to
    the node 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 packets (with different IPv4 identification
    field - ip_id), and may be able to put the target machine into mbuf
    starvation state.

    Recently we introduced a new sysctl(3) - net.inet.ip.maxfragpackets.
    With this, you can configure an upper limit to the number of reassembly
    queues. If you want the old behavior (no limit), you can set the
    value to a negative value.

    Solutions and Workarounds
    =========================

      (1) Upgrade the system from newer sources or binaries:

            Compile and install a kernel which has the sysctl(3) variable
            net.inet.ip.maxfragpackets in the sysctl MIB. With this
            variable, you can limit the number of IPv4 fragment reassembly
            queues kept on the system. The value needs to be picked
            carefully, considering the role of the node (i.e. if the
            node is a busy web server, you may want to set the value
            higher). Note that, however, even with the configuration
            knob, it is possible for attackers to transmit a lot of
            bogus IPv4 fragmented packets, and prevent other fragmented
            IPv4 traffic from getting reassembled. Unfragmented IPv4
            communication will be kept safe by the variable.

            Systems running NetBSD-current dated from before April 17,
            2001 should be upgraded to NetBSD-current dated April 17,
            2001 or later.

            Systems running NetBSD 1.5.x systems dated from before
            April 24, 2001 should be upgraded to NetBSD 1.5.x dated
            April 24, 2001 or later.
            NetBSD 1.5.1 will ship with the fix.

            There is no fix to 1.4.x available at this time.

      (2) Increase the kernel option NMBCLUSTERS

            Use an appropriate value for NMBCLUSTERS for the node.
            Normally, it is the cluster mbufs which go into a starvation
            state with this attack. By setting NMBCLUSTERS to a higher
            value, you may be able to prevent the mbuf memory pool from
            starving.

            Note that a couple of NetBSD device drivers pre-allocate
            cluster mbufs within the driver, for performance reasons
            and DMA management reasons. For example, the fxp driver
            pre-allocates 64 cluster mbufs per interface. If you
            are using such network cards, you will want to raise
            NMBCLUSTERS even more.

    Thanks To
    =========

    James Thomas for bringing this problem to our attention, and
    Jun-ichiro Hagino for providing a fix for the problem.

    Revision History
    ================

            2001-05-29 - Initial Release

    More Information
    ================

    An up-to-date PGP signed copy of this release will be maintained at
      ftp://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2001-006.txt.asc

    Information about NetBSD and NetBSD security can be found at
    http://www.NetBSD.ORG/ and http://www.NetBSD.ORG/Security/.

    Copyright 2001, The NetBSD Foundation, Inc. All Rights Reserved.

    $NetBSD: NetBSD-SA2001-006.txt,v 1.7 2001/05/29 05:58:41 lukem Exp $
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.0.5 (NetBSD)
    Comment: For info see http://www.gnupg.org

    iQCVAwUBOxM/fz5Ru2/4N2IFAQGTpQP/bG+a2FXaX8Z0i2SgE5ybx5h4FSemmazW
    iy/k+XkXnvQck+WDuRdHx6PtbQvLA203CRjGWDu7XkLEGDa6J3hgVQ2v0559BAyF
    KI3J0a4kh9RIo7rP6MRKQPaYH9N9EUtfrws7TFIibK9RVi2RebcIMaaKdvq0+EgO
    ElwTeh1cADc=
    =POjn
    -----END PGP SIGNATURE-----