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

Pages in the Historical section of this site are provided for historical purposes, they are no longer maintained. Links may not work.

Skip to end of metadata
Go to start of metadata
Original release date: November 30, 2000
Last updated: December 4, 2000
Source: CERT/CC

A complete revision history is at the end of this file.

Systems Affected

  • Many network-aware systems and applications


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.

Information from BindView's RAZOR team can be found at

This vulnerability has been assigned the CVE candidate number CAN-2000-1039.

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

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:

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 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.



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.


IBM's AIX operating system is potentially vulnerable to most of these DoS attacks. We are continuing to explore ways to defend against such attacks.

For DoS attacks that employ applications we will likely have to find defenses on a case-by-case basis.

We will keep our customers apprised of our efforts and results via various computer- and network-security related newsgroups and mailing lists (e.g, BUGTRAQ and IBM's ERS).


Microsoft Windows 2000 is not affected.

Information and patch pertaining to Microsoft Windows NT 4.0 is available at
For Microsoft Windows 9x and ME, disabling file and printer sharing prevents your exposure to this kind of attack. For more information, please see

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.


  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
  3. Denial of Service Attacks, available at
  4. Results of the Distributed-Systems Intruder Tools Workshop, available at

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.

Copyright 2000 Carnegie Mellon University.

Revision History

Nov 30, 2000: Initial Release
Nov 30, 2000: Added information from IBM
Dec 01, 2000: Minor modification to the Microsoft statement
Dec 04, 2000: Added references to BindView and CVE information. 
  • No labels