LinuxSecurity.com
Share your story
The central voice for Linux and Open Source security news
Home News Topics Advisories HOWTOs Features Newsletters About Register

Welcome!
Sign up!
EnGarde Community
Login
Polls
What is the most important Linux security technology?
 
Advisories
Community
Linux Events
Linux User Groups
Link to Us
Security Center
Book Reviews
Security Dictionary
Security Tips
SELinux
White Papers
Featured Blogs
All About Linux
DanWalsh LiveJournal
Securitydistro
Latest Newsletters
Linux Security Week: April 7th, 2014
Linux Advisory Watch: April 4th, 2014
Subscribe
LinuxSecurity Newsletters
E-mail:
Choose Lists:
About our Newsletters
RSS Feeds
Get the LinuxSecurity news you want faster with RSS
Powered By

  
NetBSD: fragmented IPv4 packets vulnerability Print E-mail
User Rating:      How can I rate this item?
Posted by LinuxSecurity.com Team   
NetBSD Malicious parties may be able to prevent a NetBSD node from communicating with other nodes by transmitting a lot of bogus fragmented IPv4 packets.

                 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 $


 
< Prev   Next >
    
Partner

 

Latest Features
Peter Smith Releases Linux Network Security Online
Securing a Linux Web Server
Password guessing with Medusa 2.0
Password guessing as an attack vector
Squid and Digest Authentication
Squid and Basic Authentication
Demystifying the Chinese Hacking Industry: Earning 6 Million a Night
Free Online security course (LearnSIA) - A Call for Help
What You Need to Know About Linux Rootkits
Review: A Practical Guide to Fedora and Red Hat Enterprise Linux - Fifth Edition
Yesterday's Edition
Partner Sponsor

Community | HOWTOs | Blogs | Features | Book Reviews | Networking
 Security Projects |  Latest News |  Newsletters |  SELinux |  Privacy |  Home
 Hardening |   About Us |   Advertise |   Legal Notice |   RSS |   Guardian Digital
(c)Copyright 2014 Guardian Digital, Inc. All rights reserved.