Information for AIX
Well, all the information I have had here has been updated, thanks to this post from IBM.
From davy@vnet.ibm.com Fri Dec 6 00:12:35 1996
Date: Tue, 03 Dec 1996 13:48:28 EST
From: "David A. Curry"
To: mike@opac.bl.uk
Subject: ping
Please update your Ping o' Death page to include the following information
about patches for IBM AIX.
Thanks,
--Dave
David A. Curry IBM Internet Emergency Response Service
Senior Internet Security Analyst 300 Long Meadow Road, M/S 227
Information Warfare Center Sterling Forest, NY 10979-0700 U.S.A.
davy@vnet.ibm.com +1 914 759-4452
-----BEGIN PGP SIGNED MESSAGE-----
- --ERS-ALERT--ERS-ALERT--ERS-ALERT--ERS-ALERT--ERS-ALERT--ERS-ALERT--ERS-ALERT--
- ---EXTERNAL RELEASE---EXTERNAL RELEASE---EXTERNAL RELEASE---EXTERNAL RELEASE---
======= ============ ====== ======
======= ============== ======= =======
=== === ==== ====== ======
=== =========== ======= =======
=== =========== === ======= ===
=== === ==== === ===== ===
======= ============== ===== === =====
======= ============ ===== = =====
EMERGENCY RESPONSE SERVICE
SECURITY VULNERABILITY ALERT
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.
===============================================================================
IBM's Internet Emergency Response Service (IBM-ERS) is a subscription-based
Internet security response service that includes computer security incident
response and management, regular electronic verification of your Internet
gateway(s), and security vulnerability alerts similar to this one that are
tailored to your specific computing environment. By acting as an extension
of your own internal security staff, IBM-ERS's team of Internet security
experts helps you quickly detect and respond to attacks and exposures across
your Internet connection(s).
As a part of IBM's Business Recovery Services organization, the IBM Internet
Emergency Response Service is a component of IBM's SecureWay(tm) line of
security products and services. From hardware to software to consulting,
SecureWay solutions can give you the assurance and expertise you need to
protect your valuable business resources. To find out more about the IBM
Internet Emergency Response Service, send an electronic mail message to
ers-sales@vnet.ibm.com, or call 1-800-742-2493 (Prompt 4).
IBM-ERS maintains a site on the World Wide Web at http://www.ers.ibm.com/.
Visit the site for information about the service, copies of security alerts,
team contact information, and other items.
IBM-ERS uses Pretty Good Privacy* (PGP*) as the digital signature mechanism for
security vulnerability alerts and other distributed information. The IBM-ERS
PGP* public key is available from http://www.ers.ibm.com/team-info/pgpkey.html.
"Pretty Good Privacy" and "PGP" are trademarks of Philip Zimmermann.
IBM-ERS is a Member Team of the Forum of Incident Response and Security Teams
(FIRST), a global organization established to foster cooperation and response
coordination among computer security teams worldwide.
Copyright 1996 International Business Machines Corporation.
The information in this document is provided as a service to customers of
the IBM Emergency Response Service. Neither International Business Machines
Corporation, Integrated Systems Solutions Corporation, nor any of their
employees, makes any warranty, express or implied, or assumes any legal
liability or responsibility for the accuracy, completeness, or usefulness of
any information, apparatus, product, or process contained herein, or
represents that its use would not infringe any privately owned rights.
Reference herein to any specific commercial products, process, or service by
trade name, trademark, manufacturer, or otherwise, does not necessarily
constitute or imply its endorsement, recommendation or favoring by IBM or
its subsidiaries. The views and opinions of authors expressed herein do not
necessarily state or reflect those of IBM or its subsidiaries, and may not be
used for advertising or product endorsement purposes.
The material in this security alert may be reproduced and distributed,
without permission, in whole or in part, by other security incident response
teams (both commercial and non-commercial), provided the above copyright is
kept intact and due credit is given to IBM-ERS.
This security alert may be reproduced and distributed, without permission,
in its entirety only, by any person provided such reproduction and/or
distribution is performed for non-commercial purposes and with the intent of
increasing the awareness of the Internet community.
- ---EXTERNAL RELEASE---EXTERNAL RELEASE---EXTERNAL RELEASE---EXTERNAL RELEASE---
- --ERS-ALERT--ERS-ALERT--ERS-ALERT--ERS-ALERT--ERS-ALERT--ERS-ALERT--ERS-ALERT--
-----BEGIN PGP SIGNATURE-----
Version: 2.7.1
iQCVAwUBMqR00PWDLGpfj4rlAQH3nQQAksez9vrmbNxr1RUsncI3qHdF3/vhVgFy
/2ZpEBTyecJ0PJBvkGPs72evdTsCr1Ai09HOJ9zS2HxP33NlaNirSQD1/gUdcBl6
uoIdE+4RUaPDim+S6TIi64Qyqs45VJ0NMsPXvvg1xaV5N0ynlLwTChimcDB68J6z
hMryi2rVXf8=
=Wx2o
-----END PGP SIGNATURE-----