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