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

CERT Advisory CA-2000-21 Denial-of-Service Vulnerabilities in TCP/IP Stacks

   Original release date: November 30, 2000
   Last updated: November 30, 2000
   Source: CERT/CC
   
   A complete revision history is at the end of this file.
   
Systems Affected

     * Many network-aware systems and applications
       
Overview

   A variety of denial-of-service vulnerabilities has been explored and
   documented by BindView's RAZOR Security Team. These vulnerabilities
   allow attackers to consume limited resources on victim machines.
   BindView's RAZOR Security Team has referred to these vulnerabilities
   as Naptha vulnerabilities.
   
I. Description

   Denial-of-service attacks are possible whenever an attacker can
   consume a limited resource on a victim's machine. Examples of the
   kinds of resources that an attacker can consume are CPU time, network
   bandwidth, and volatile and non-volatile memory. In addition,
   intruders can also attempt to consume limited data structures such as
   process slots, open file handles, or other data structures required
   for the operation of a machine or service.
   
   Recently, BindView's RAZOR Security Team has explored and documented a
   number of resource exhaustion attacks against TCP/IP services. TCP can
   be modeled as a finite state machine, consisting of eleven states
   (CLOSED, LISTEN, SYN RECVD, SYN SENT, ESTABLISHED, CLOSE WAIT, LAST
   ACK, FIN WAIT-1, FIN WAIT-2, CLOSING, and TIME WAIT) [1].
   Implementations of TCP and services that use TCP rely on limited data
   structures to implement the states of the TCP finite state machine. By
   attacking specific weaknesses in applications and implementations of
   TCP, it is possible for an attacker to cause services or systems to
   crash, refuse service, or otherwise become unstable. A related attack,
   called a "syn flood attack,"[2] exploited a weakness in how many TCP
   implementations handled a large number of connections in the "SYN
   RECVD" state. Naptha attacks exploit weaknesses in the way some TCP
   stacks and applications handle large numbers of connections in states
   other than "SYN RECVD," including "ESTABLISHED" and "FIN WAIT-1."
   
   In general, any system that allows critical resources to be consumed
   without bound is subject to denial-of-service attacks [3]. Naptha and
   similar network attacks are more dangerous for several reasons: 1)
   they can be done "asymmetrically" -- that is, the attacker can consume
   vast amounts of a victim's limited resource without a commensurate
   resource expenditure; 2) in combination with other vulnerabilities or
   weaknesses, they can be done anonymously, and 3) they can be included
   in distributed denial-of-service tools.
   
   The number and type of resources that an attacker can target for a
   denial-of-service attack are many and varied. The Naptha work
   highlights a set of them for which some specific defenses exist, as
   described in the vendor section below.
   
   The CERT/CC has not received any reports of attacks based on Naptha
   vulnerabilities being exploited. If you notice an unusual number of
   connections in a particular state, it may be an indication of this
   type of attack. The definition of "unusual" in this case depends
   largely on the types of services offered on your machine. For example,
   a large number of connections in the ESTABLISHED state on a web server
   may simply be an indication of a busy web server. Understanding the
   normal usage patterns of services you offer may help you distinguish
   an attack from ordinary activity. Many operating systems offer a
   netstat utility that is useful for examining the state of
   connections.
   
II. Impact

   Vulnerable services can be disrupted or seriously degraded. In some
   cases, the host operating system may crash or hang.
   
III. Solution

Apply a patch from your vendor

   Some vendors have provided patches that "harden" their systems to
   degrade gracefully or to probabilistically refuse service under
   certain conditions. In these cases, we recommend applying such a
   patch.
   
Tune your operating system appropriately

   Some vendors provide the ability to "tune" your operating system to be
   more resilient to these types of attacks. In those cases, we encourage
   you to make the tuning choices appropriate for your requirements and
   risk tolerance.
   
Prepare for denial-of-service attacks in general, and be a "good citizen"

   Effectively responding to denial-of-service attacks requires planning
   prior to the attacks. In the short term, actions include ingress
   filtering and disabling directed broadcasts. For more information, see
   Results of the Distributed Systems Intruder Tools Workshop [4].
   
Appendix A. Vendor Information

Compaq Computer Corporation

   COMPAQ COMPUTER CORPORATION
   Software Security Response Team
   ------------------------------------------------------
   x-ref: naptha
   
   At the time of writing this document, Compaq is currently
   investigating the potential impact to Compaq's operating systems.
   Compaq views the problem to be a great concern, however Tru64 UNIX
   servers have tuning features that allow them to withstand an attack
   such as is in naptha.
   
   Please consult the Compaq Tru64 UNIX documentation on performance
   tuning. Our internet tuning guide discusses syn-ack attacks and how to
   tune Tru64 UNIX to be less susceptible to the attack. Essentially you
   increase the size of the queue resources Tru64 UNIX will need for all
   connections, and since many of the syn-ack attacks don't form a
   complete connection, they get timed out and deleted. The guide is at:
   http://www.unix.digital.com/internet/tuning.htm.
   
   Setting the value of a parameter, sominconn, to 65535 will make Tru64
   UNIX more hardened against the SYN attack identified in the recent
   discussions. This change can be made using the following command:
   # /sbin/sysconfig -r socket sominconn=65535
   # /sbin/sysconfig -r socket somaxconn-65535
   
   A reboot is not required, but, to make the change permanent you should
   use either sysconfigdb or dxkerneltuner.
   ADDITIONAL COMMENTS:
   
   Additional information that may help to understand how/why the changes
   need to be made.
   
   sominconn/somaxconn are two parameters that deal with socket listen
   queues. You can improve the handling by increasing the numbers.
   Default settings are 1024 for somaxconn and 0 for sominconn.
   Generally, on busy web servers, we recommend they be set to 65535 for
   both. The attribute allows handling more sockets in queued SYN_RCVD
   state. There are other socket attributes to watch,
   
          The sobacklog_hiwat attribute counts the maximum number of pending
          requests to any server socket.
          
          The sobacklog_drops attribute counts the number of times the
          system dropped a received SYN packet, because the number of
          queued SYN_RCVD connections for a socket equaled the socket's
          backlog limit.
          
          The somaxconn_drops attribute counts the number of times the
          system dropped a received SYN packet, because the number of
          queued SYN_RCVD connections for the socket equaled the upper
          limit on the backlog length (somaxconn attribute).
          
   It is recommended that the value of the sominconn attribute equal the
   value of the somaxconn attribute. If so, the value of somaxconn_drops
   will have the same value as sobacklog_drops.
   
   However, if the value of the sominconn attribute is 0 (the default),
   and if one or more server applications uses an inadequate value for
   the backlog argument to its listen system call, the value of
   sobacklog_drops may increase at a rate that is faster than the rate at
   which the somaxconn_drops counter increases. If this occurs, you want
   to increase the value of the sominconn attribute. As further
   information becomes available Compaq will provide notice of the
   completion/availability of any necessary patches, or tuning
   recommendations through AES services (DIA, DSNlink FLASH and posted to
   the Services WEB page) and be available from your normal Compaq
   Services Support channel.
   
                   COMPAQ COMPUTER CORPORATION
   
FreeBSD

   For a remote attacker, the scope of the attack is severely limited by
   the requirement to complete a TCP connection with the victim machine,
   meaning the IP address of the attacking machine is disclosed, and as
   such the attack can be effectively responded to through the use of
   tracing, filtering and legal mechanisms. However, work is underway to
   develop improvements to FreeBSD network services to reduce their
   vulnerability to this type of attack, recognizing that the time
   between attack onset and effective administrative response may be
   substantial.
   
Microsoft

   Microsoft Windows 2000 is not affected.
   
   Information pertaining to Microsoft Windows NT 4.0 is available at
   
   http://www.microsoft.com/technet/security/bulletin/MS00-091.asp
          
   A patch for Windows NT is available at
   
   http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25114
          
   For Microsoft Windows 9x and ME, disabling file and printer sharing
   prevents your exposure to this kind of attack. For more information,
   please see
   
   http://support.microsoft.com/support/kb/articles/Q199/3/46.ASP
          
Sun Microsystems, Inc.

   Currently a connection between two Solaris boxes is not vulnerable to
   the exploit in its present form. However, Solaris may have an issue
   with variations of this attack. Sun is still investigating and will
   provide updates when more information or a remedy is available.
   
References

    1. Internetworking with TCP/IP, Volume 2, (Prentice-Hall, 1991), p.
       174.
    2. CERT Advisory CA-1996-21: TCP Syn Flooding and IP Spoofing
       Attacks, available at
       http://www.cert.org/advisories/CA-1996-21.html
    3. Denial of Service Attacks, available at
       http://www.cert.org/tech_tips/denial_of_service.html
    4. Results of the Distributed-Systems Intruder Tools Workshop,
       available at http://www.cert.org/reports/dsit_workshop-final.html
     _________________________________________________________________
   
   The CERT Coordination Center thanks Bob Keyes of BindView's RAZOR team
   for discovering the vulnerability, and Robert Watson (NAI Labs,
   FreeBSD Project) and Alan Cox, Red Hat Inc., for technical assistance.
   In addition, we thank Steve Bellovin of AT&T and Wietse Venema of IBM
   for their input on this advisory.
     _________________________________________________________________
   
   Author: This document was written by Shawn Hernan. Feedback on this
   advisory is appreciated.
   ______________________________________________________________________
   
   This document is available from:
   http://www.cert.org/advisories/CA-2000-21.html
   ______________________________________________________________________
   
CERT/CC Contact Information

   Email: cert@cert.org
          Phone: +1 412-268-7090 (24-hour hotline)
          Fax: +1 412-268-6989
          Postal address:
          CERT Coordination Center
          Software Engineering Institute
          Carnegie Mellon University
          Pittsburgh PA 15213-3890
          U.S.A.
          
   CERT personnel answer the hotline 08:00-20:00 EST(GMT-5) / EDT(GMT-4)
   Monday through Friday; they are on call for emergencies during other
   hours, on U.S. holidays, and on weekends.
   
Using encryption

   We strongly urge you to encrypt sensitive information sent by email.
   Our public PGP key is available from
   
   http://www.cert.org/CERT_PGP.key
       
   If you prefer to use DES, please call the CERT hotline for more
   information.
   
Getting security information

   CERT publications and other security information are available from
   our web site
   
   http://www.cert.org/
       
   To subscribe to the CERT mailing list for advisories and bulletins,
   send email to majordomo@cert.org. Please include in the body of your
   message
   
   subscribe cert-advisory
   
   * "CERT" and "CERT Coordination Center" are registered in the U.S.
   Patent and Trademark Office.
   ______________________________________________________________________
   
   NO WARRANTY
   Any material furnished by Carnegie Mellon University and the Software
   Engineering Institute is furnished on an "as is" basis. Carnegie
   Mellon University makes no warranties of any kind, either expressed or
   implied as to any matter including, but not limited to, warranty of
   fitness for a particular purpose or merchantability, exclusivity or
   results obtained from use of the material. Carnegie Mellon University
   does not make any warranty of any kind with respect to freedom from
   patent, trademark, or copyright infringement.
     _________________________________________________________________
   
   Conditions for use, disclaimers, and sponsorship information
   
   Copyright 2000 Carnegie Mellon University.
   
   Revision History
Nov 30, 2000: Initial Release

-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQCVAwUBOiayEAYcfu8gsZJZAQE0EwP9HNmRzXCdrsFWhiHAXPW0/66TsfGbBzxd
gXb7AmtKhQRmKiYrk33ddRFWiHFX2cMJtNtAL6vXWUywmhQbCE/ZHnYeXSeePZ1r
61/8Eldf0o4O3QXWdh/fzKr4ewXx1mbysswedQtGUx2BsB/h2YAZkha1miDZxDF1
ZUtw4N+VJ+c=
=iw33
-----END PGP SIGNATURE-----