-----BEGIN PGP SIGNED MESSAGE----- =============================================================================== Security Advisory CERT-NL =============================================================================== Author/Source : Gert Meijerink Index : S-96-61.IBM Distribution : World Page : 1 Classification: External Version: 1 Subject : Patches for IBM AIX(r) Address `SYN Date : 3-dec-96 Flood' and `Ping o' Death' Vulnerabilities =============================================================================== By courtesy of IBM-ERS we received information on Newly Available Patches for IBM AIX(r) Address `SYN Flood' and `Ping o' Death' Vulnerabilities ******************************************************************************* Note that this vulnerability has been reported to exist on other systems (including printers, routers and other firmware). As soon as CERT-NL receives additional information on this, advisories will be issued under the number S-96-61 with a system specific extension. ******************************************************************************* CERT-NL recommends that the information in the following IBM-ERS Security Bulletin should be acted upon as soon as possible. =============================================================================== 03 December 1996 18:30 GMT Number: ERS-SVA-E01-1996:006.1 =============================================================================== Newly Available Patches for IBM AIX(r) Address `SYN Flood' and `Ping o' Death' Vulnerabilities =============================================================================== CONTENTS I. Introduction and Background A. The SYN Flood Attack B. The "Ping o' Death" Attack II. AIX Systems Affected A. The SYN Flood Attack B. The "Ping o' Death" Attack III. Fixes for IBM AIX A. The SYN Flood Attack B. The "Ping o' Death" Attack IV. Fixes for IBM SNG Firewall V. Obtaining Fixes VI. Acknowledgements =============================================================================== I. Introduction and Background In recent weeks, two network protocol security vulnerabilities have received attention throughout the Internet community. These vulnerabilities are described below. The information in this section is not new; it has been published on the Internet and elsewhere. It is repeated here for completeness, and for those readers who are unfamiliar with either vulnerability. A. The SYN Flood Attack The first of these vulnerabilities, commonly called the "SYN Flood Attack," was publicized by the New York Times and other news media in September, 1996. The exploitation of this vulnerability takes advantage of the Transmission Control Protocol (TCP) connection establishment procedure, usually called the "three-way handshake." The three-way handshake works as follows: Suppose that Host A wants to connect to Host B: 1. Host A begins the process of establishing the connection by sending a SYN (synchronization) packet to Host B. This packet requests a new connection on a particular port, and begins the process of negotiating connection details such as packet sequence numbers. 2. Host B responds by sending a SYN/ACK (synchronization/acknowledgement) packet back to A. This packet acknowledges Host A's packet, and goes one step further in negotiating the connection details. 3. Host A sends a final ACK (acknowledgement) packet back to Host B; this acknowledges Host B's packet, finalizes the negotiations of connection details, and the connection is established. The three-way handshake is designed to work properly even if one of the packets gets lost or duplicated, which can happen from time to time (as a part of normal operations). During the time between steps 2 and 3, Host B must keep track of the pending new connection by storing the details of the negotiation in an in-memory data structure. This data structure is usually of finite size, which means that too many pending connections at one time can cause it to overflow. When this happens, Host B will be unable to accept any new connections at all until some of the pending connections have been fully established (or have timed out), freeing space in the data structure. The basic SYN flood attack works by sending a high volume of SYN packets to the target host, and then never responding to the SYN/ACK packets that are returned, thus filling up the data structure(s) used by the target host to keep track of pending connections. Although pending connections will time out eventually and free up space in the data structure(s), the sender can simply transmit additional SYN packets, faster than they can expire. In another possible scenario, the sender takes advantage of the fact that since he is ignoring the target host's SYN/ACK packets, he doesn't even need to receive them. This allows him to hide his location by using a forged address in the SYN packets his system sends -- he can use the real address of another system (thus misleading the target), or he can use a non-existent address (and simply hiding). At least one of the attack programs currently in use on the Internet makes up a new, random source address for each packet it sends. For more complete information on the SYN Flood attack, see ftp://info.cert.org/pub/cert_advisories/CA-96.21.tcp_syn_flooding B. The "Ping o' Death" Attack The second vulnerability, which has been dubbed the "Ping o' Death," takes advantage of the ability of the Internet Protocol (the protocol on top of which all other Internet protocols are built) to fragment packets. This works as follows: The specification for the Internet Protocol (IP) says that a packet may be up to 65,535 (2^16 - 1) bytes in length, including the packet header. But the specifications for most network technologies in use today do not allow packets that big. For example, the maximum Ethernet packet size is 1,500 bytes. To allow large packets to be sent, IP allows the sender to break a large packet up into several smaller packets. Each fragment packet contains an offset value that says where in the larger packet this fragment belongs -- the first fragment will have an offset of zero, the second fragment will have an offset equal to the length of the first fragment, and so on. Note that this makes it possible to combine a valid offset with a suitable fragment size such that (offset + size) is greater than 65,535, the maximum size of a packet. The problem arises in the way packet fragmentation is implemented by most systems. Typically, they do not attempt to process a packet until all the fragments have been received and an attempt has been made to reassemble them into one big packet. This opens these systems to the possibility for overflow of 16-bit internal variables, resulting in system crashes, protocol hangs, and other problems. This problem was first discovered in the context of sending ICMP ECHO REQUEST packets, commonly called "ping" packets after the application program used to send them. Most implementations of "ping" will not allow improperly-sized packets to be sent, although there are several exceptions to this (and many systems can be modified to allow it, in any case). Because sending a single, large (65,510 bytes) "ping" packet to many systems will cause them to hang or even crash, this problem was quickly dubbed the "Ping o' Death." For complete information on the Ping o' Death, see Mike Bremford's compilation of specific software vulnerabilities: http://www.sophist.demon.co.uk/ping/ II. AIX Systems Affected A. The SYN Flood Attack Any system that is connected to a TCP/IP-based network (Internet or intranet) and offers TCP-based services is vulnerable to the SYN flood attack. The attack does not distinguish between operating systems, software version levels, or hardware platforms; all systems are vulnerable. Because this attack takes advantage of the TCP protocol itself, it cannot be eliminated without changing the protocol. However, it is possible to make changes to the implementation of the connection establishment procedure that can mitigate the problems caused by the attack, and several vendors have either made such changes or are in the process of making them. B. The "Ping o' Death" Attack Not all operating systems are vulnerable to this problem. However, most of the popular operating systems in use today are vulnerable, to some degree, under certain circumstances. This problem is not limited to the UNIX system; it occurs in many personal computer operating systems, some midrange and mainframe systems, and several more specialized operating systems (terminal servers, network printers). Unlike the SYN flood attack, this problem is due to the implementation of fragmented packet reassembly, and is thus relatively easy to fix. Several vendors have either made patches for this problem available, or are in the process of doing so. III. Fixes for IBM AIX IBM has released AIX operating system fixes for both the SYN flood and "Ping o' Death" vulnerabilities. NOTE: If you are using the IBM Internet Connection Secured Network Gateway (SNG) firewall software, you must also apply the fixes listed in the next section. A. The SYN Flood Attack The following Automated Program Analysis Reports (APARs) for IBM AIX are now available to address the SYN flood attack: AIX 3.2.5 --------- No APAR available; upgrade to AIX 4.x recommended AIX 4.1.x --------- APAR - IX62476 AIX 4.2.x --------- APAR - IX62428 B. The "Ping o' Death" Attack The following Automated Program Analysis Reports (APARs) for IBM AIX are now available to address the "Ping o' Death" Attack: AIX 3.2.5 --------- APAR - IX59644 AIX 4.1.x --------- APAR - IX59453 AIX 4.2.x --------- APAR - IX61858 If you are running AIX 4.x, you can determine whether or not you have these fixes installed on your system by issuing the command instfix -ik APAR_ID where "APAR_ID" is the applicable "IXnnnnn" number from the list above. IV. Fixes for IBM SNG Firewall The following Automated Program Analysis Reports (APARs) for the IBM Internet Connection Secured Network Gateway firewall product are now available to address the SYN flood and "Ping o' Death" attacks: NOTE: The fixes in this section should ONLY be applied to systems running the IBM Internet Connection Secured Network Gateway (SNG) firewall software. They should be applied IN ADDITION TO the IBM AIX fixes listed in the previous section. IBM SNG V2.1 ------------ APAR - IR33376 PTF UR46673 IBM SNG V2.2 ------------ APAR - IR33484 PTF UR46641 V. Obtaining Fixes IBM AIX APARs may be ordered using Electronic Fix Distribution (via the FixDist program), or from the IBM Support Center. For more information on FixDist, and to obtain fixes via the Internet, please reference http://service.software.ibm.com/aixsupport/ or send electronic mail to "aixserv@austin.ibm.com" with the word "FixDist" in the "Subject:" line. VI. Acknowledgements AIX is a registered trademark of International Business Machines Corporation. Copyright 1996 International Business Machines Corporation. =============================================================================== ============================================================================== CERT-NL is the Computer Emergency Response Team for SURFnet customers. SURFnet is the Dutch network for educational, research and related institutes. CERT-NL is a member of the Forum of Incident Response and Security Teams (FIRST). All CERT-NL material is available uder: t.nl/surfnet/security/cenrt-nl.html ftp://ftp.surfnet.nl/surfnet/net-security In case of computer or network security problems please contact your local CERT/security-team o CERT-NL (if your insti stomer please address the appropriate (local) CERT/security-team). CERT-NL is one/two hour(s) ahead of UTC (GMT) in winter/summer, i.e. UTC+0100 in winter and UTC+0200 in summer (DST). Emil: cert-nl@surfnet.Fnl Phone: +31 305 305 Fax: +31 302 305 329 Snailmail: SURFnet bv Attn. CERT-NL P.O. Box 19035 NL - 3501 DA UTRECHT The Netherlands A 7 * 24 hours phone number is available to SURFnet SSC's and FIRST members on request. ============================================================================== -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: cp850 iQCVAwUBMqSXk2L2fnkJN/jpAQEQCgP/QeBLCuho7b093Ws7/VWD2Po7YWpLeYOS o0B9uOzGHWigRjq3ZhyhuGLZjNgtYEpU6JjvhPNqwnksUQZdtTczx3B5wWscLxyS 09DeqCtaQIoT0EeaZjD4ltWGxmpjSgZITB24Po++9LwMnIx4P4+kbE3h6eDTiLEc SEzKREi0gdE= =CEWp -----END PGP SIGNATURE-----