Original release date: November 30, 2000<BR>
Last updated: December 4, 2000<BR>
Source: CERT/CC<BR>
<P>A complete revision history is at the end of this file.
<A NAME="affected"></a>
<H3>Systems Affected</H3>
<ul>
<li>Many network-aware systems and applications </li>
</ul>
<A NAME="overview"></a>
<H2>Overview</H2>
<p>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.
<A NAME="description"></a>
<H2>I. Description</H2>
<p>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.
<p>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) <A
HREF="#Ref1">[1]</a>. 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,"<A
HREF="#Ref2">[2]</a> 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."</p>
<p>In general, any system that allows critical resources to be
consumed without bound is subject to denial-of-service attacks <A
HREF="#Ref3">[3]</a>. 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.</p>
<p>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.
<P>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
<i>netstat</i> utility that is useful for examining the state of
connections.
<p>Information from BindView's RAZOR team can be found at
<dl>
<dd><A
HREF="http://razor.bindview.com/publish/advisories/adv_NAPTHA.html">http://razor.bindview.com/publish/advisories/adv_NAPTHA.html</a>
</dd>
</dl>
<p>This vulnerability has been assigned the CVE candidate number
<A HREF="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2000-1039">
CAN-2000-1039</a>.
<A NAME="impact"></a>
<H2>II. Impact</H2>
<p>Vulnerable services can be disrupted or seriously degraded. In
some cases, the host operating system may crash or hang.</p>
<A NAME="solution"></a>
<H2>III. Solution</H2>
<H4>Apply a patch from your vendor</H4>
<p>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.</p>
<H4>Tune your operating system appropriately</H4>
<p>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.</p>
<H4>Prepare for denial-of-service attacks in general, and be a "good
citizen"</H4>
<p>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 <i>Results of the Distributed Systems Intruder Tools
Workshop</i> <A HREF="#Ref4">[4]</a>.
<A NAME="vendors"></a>
<H2>Appendix A. Vendor Information</H2>
<A NAME="compaq"></a>
<H4>Compaq Computer Corporation</H4>
COMPAQ COMPUTER CORPORATION<br>
Software Security Response Team<br>
------------------------------------------------------<br>
x-ref: naptha<br>
<p>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.
<p>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:
<A
HREF="http://www.unix.digital.com/internet/tuning.htm">http://www.unix.digital.com/internet/tuning.htm</a>.
<p>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:
<br>
# /sbin/sysconfig -r socket sominconn=65535<br>
# /sbin/sysconfig -r socket somaxconn-65535<br>
<p>A reboot is not required, but, to make the change permanent you should
use either sysconfigdb or dxkerneltuner. <br>
<br><b>ADDITIONAL COMMENTS:</b><br>
<p>Additional information that may help to understand how/why the changes
need to be made.
<p>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,
<dl>
<dd>The sobacklog_hiwat attribute counts the maximum number of pending
requests to any server socket.</dd>
<p>
<dd>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.</dd>
</p>
<p>
<dd>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).</dd>
</p>
</dl>
<p>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.
<p>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.
<p> COMPAQ COMPUTER CORPORATION
<H4>FreeBSD</H4>
<p>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.
<H4>IBM</H4>
<p>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.
<p>For DoS attacks that employ applications we will likely have to
find defenses on a case-by-case basis.
<p>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).
<H4>Microsoft</H4>
Microsoft Windows 2000 is not affected.
<p>Information and patch pertaining to Microsoft Windows NT 4.0 is
available at
<dl><dd><A
HREF="http://www.microsoft.com/technet/security/bulletin/MS00-091.asp">http://www.microsoft.com/technet/security/bulletin/MS00-091.asp</a>
</dl></dd>
For Microsoft Windows 9x and ME, disabling file and printer sharing
prevents your exposure to this kind of attack. For more information,
please see
<dl><dd>
<A
HREF="http://support.microsoft.com/support/kb/articles/Q199/3/46.ASP">http://support.microsoft.com/support/kb/articles/Q199/3/46.ASP</a>
</dd>
</dl>
<H4>Sun Microsystems, Inc.</H4>
<p>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.</p>
<H2>References</H2>
<ol>
<A NAME=Ref1></a>
<li><i>Internetworking with TCP/IP, Volume 2,</i> (Prentice-Hall, 1991), p.
174.</li>
<A NAME=Ref2></a>
<li><i>CERT Advisory CA-1996-21: TCP Syn Flooding and IP Spoofing
Attacks</i>, available at <A
HREF="http://www.cert.org/advisories/CA-1996-21.html">http://www.cert.org/advisories/CA-1996-21.html</a></li>
<A NAME=Ref3></a>
<li><i>Denial of Service Attacks</i>, available at <A HREF="
http://www.cert.org/tech_tips/denial_of_service.html">
http://www.cert.org/tech_tips/denial_of_service.html</a></li>
<A NAME=Ref4></a>
<li><i>Results of the Distributed-Systems Intruder Tools Workshop</i>,
available at <A HREF="http://www.cert.org/reports/dsit_workshop-final.html">http://www.cert.org/reports/dsit_workshop-final.html</a>
</ol>
<HR NOSHADE>
<P>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.
<HR NOSHADE>
<P>Author: This document was written by Shawn Hernan.
<A HREF="mailto:cert@cert.org?subject=CA-2000-21%20Feedback%20VU%23946799">
Feedback</A> on this advisory is appreciated.
<P>
<!--#include virtual="/include/footer_nocopyright.html" -->
<P>Copyright 2000 Carnegie Mellon University.</P>
<P>Revision History
<FONT FACE="monospace">
<PRE>
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.
</PRE>
</FONT>
|