It's the Ping o' Death Page!

How to crash your operating system!

Maintained by Malachi Kenney, last updated 1/22/97, 1800 GMT
Please mail me with any updates, corrections or new information, being sure to include the word "ping" in the subject line.
List of mirror sites
The Ping o'Death diary - new information in the order it's received
The primary site moved to (seems to be offline as of Feb. 1999) on 1/22/97. Great thanks to Mike Bremford, who started this site and maintained it through the the period of constant updating.
Javier Romeu of RED Security has done a brilliant job of translating all the pages to Spanish (I have enough trouble maintaining them in English...). They're available here.

1. The Problem

In a nutshell, it is possible to crash, reboot or otherwise kill a large number of systems by sending a ping of a certain size from a remote machine. This is a serious problem, mainly because this can be reproduced very easily, and from a remote machine. (During tests, my machine in London, England has been crashed from a machine in Berkeley, California), and because the attacker needs to know nothing about the machine other than its IP address. Be afraid. Since I started this page on the 21st October, over 18 major operating systems have been found vulnerable.

It's very easy to exploit - basically, some systems don't like being pinged with a packet greater than 65536 bytes (as opposed to the default 64 bytes). This bug is not limited to Unix, but is popping up on Macs, Netware, Printers, Routers... the list goes on. Patches are coming out extremely fast - the award did go to the Linux community for getting a patch out within three hours (well, 2 hours 35 minutes 10 seconds if you must know), but Bill Webb from Telebit assures me that the Netblazer patch was out within two! OK, OK, you can share the prize money... :-)

An IP datagram of 65536 bytes is illegal, but possible to create owing to the way the packet is fragmented (broken into chunks for transmission). When the fragments are reassembled at the other end into a complete packet, it overflows the buffer on some systems, causing (variously) a reboot, panic, hang, and sometimes even having no effect at all...

Most implementations of ping won't allow an invalid datagram like this to be sent. Among the exceptions are Windows '95 and NT, although they are certainly not the only ones...

1.1 A far better explanation of the problem

Thanks to Paul Gortmaker we now have a decent explanation of why this is happening

Background Information on ICMP ECHO ("ping"):

IP packets as per RFC-791 can be up to 65,535 (2^16-1) octets long, which includes the header length (typically 20 octets if no IP options are specified). Packets that are bigger than the maximum size the underlyling layer can handle (the MTU) are fragmented into smaller packets, which are then reassembled by the receiver. For ethernet style devices, the MTU is typically 1500.

An ICMP ECHO request "lives" inside the IP packet, consisting of eight octets of ICMP header information (RFC-792) followed by the number of data octets in the "ping" request. Hence the maximum allowable size of the data area is 65535 - 20 - 8 = 65507 octets.

What causes my machine to crash from this?

Note that it is possible to send an illegal echo packet with more than 65507 octets of data due to the way the fragmentation is performed. The fragmentation relies on an offset value in each fragment to determine where the individual fragment goes upon reassembly. Thus on the last fragment, it is possible to combine a valid offset with a suitable fragment size such that (offset + size) > 65535. Since typical machines don't process the packet until they have all fragments and have tried to reassemble it, there is the possibility for overflow of 16 bit internal variables, which can lead to system crashes, reboots, kernel dumps and the like.

1.2 Another twist...

With all this talk of ping, it's easy to miss the root of the problem. Joel Maslak has pointed out that this exploit is by no means restricted to ping. The problem can be exploited by anything that sends an IP datagram - probably the most fundamental building block of the net. Not only ICMP echo, but TCP, UDP and (apparently) even new style IPX can be used to hit machines where it hurts.

Bottom line is that blocking ping at the firewall is a temporary fix only. The only solution is to secure the kernel against overflow when reconstructing IP fragments. (To the best of my knowledge, all of the patches currently available fix the problem). So don't think you're safe just because you've blocked ping. Damage could be done through NFS, telnet, http... in short, any port your machine listens on is a target (and maybe even those you don't listen on... anyone?)

2. How to test if you're vulnerable

Unfortunately, this bug is really easy to exploit. Users are already trying it out "just to see if it worked". So, to test if your machine is in danger, find a Windows '95 or NT box (3.51 or 4), and run the following command:

ping -l 65510

The message on the '95 box will be "Request Timed Out". This means that the ping wasn't answered, either because the machine is ignoring you (and rightly so if you're going to send it invalid packets), or because it's dead. It's that simple...

3. How to prevent people from breaking your system

If no patch is available, and your main concern are pings from users outside your network, it would seem the best quick-fix solution is to block ping at the firewall. This is not a long-term solution. If you have *any* services listening on any ports at all, they are vulnerable. Be assured that sooner or later someone will come out with a program which sends invalid packets to a web server, an ftp port. The only solution is to patch your operating system.

By blocking ping, you prevent people from pinging you at all. This could possibly break some things that rely on ping - I believe that DEC ObjectBroker uses ping to confirm a connection is still up. Other packages may go too.

A better solution than blocking all pings is to block only fragmented pings. This will allow your common-or-garden 64 byte ping through on almost all systems, while blocking any bigger than the MTU size of your link. (This varies, but about 1k is a good bet).

4. The affected systems

This is very much a work in progress. Please, any additional information you come by mail me so I can update this page. Please include the word "ping" in the subject line

4.1. Vulnerable operating systems without patches

This includes systems which I haved mixed reports on
Operating systemVersionSymptomsComments
Solaris (x86)2.4RebootPatches are available for 2.5 and 2.5.1, but there are no patches for 2.4.
Minix1.7.4, v2.0 and probably othersCrashNo fix yet
HP3000 MPE/iX4.0, 5.0, 5.5System abortThe exact message was "System abort 3890 from subsys 201".
Convex SPP-UXAll versionsCrashNo fix yet, but Convex are working on a patch.
AOS??This is suspected to be vulnerable, based on its BSD 4.3 heritage. However, only one person has been able to crash it yet, using a 32768 byte packet
KA9Q OS?CrashNo fix yet
NEXTSTEPvariousPlatform dependantNext have tested this, follow the link for more info. The vulnerability is to a 32768 byte packet
Apple MacMacOs 7.x.xCrashSee the Mac page for details
Windows 3.11 with Trumpet Winsock?Mixed reportsOne person has had no problems, another two get network errors and lose the network connection - the machine had to be rebooted to restore it
Windows 3.11 with FTP software PCTCP 4.0, Chameleon NFS 5.4, Digital Pathworks stack 6.0.034 and LINK TCP stack-HangsNo fix...
MSDOS with Lan Workplace?CrashNo fix yet
Novell Netware3.xMixed resultsRanging from crash to no effect. 3.11 with TCPIP.NLM v1.01 hangs the IP stack (IPX/SPX stack is OK), while 3.12 with TCPIP.NLM v2.02 rev 9 is unaffected.
SCO Open Desktop, Internet FastStart, SCO Unix SysV/386?VulnerableSCO have found this vulnerable. Again, see the CERT advisory. The problem is network card dependant - at least the NE2000 and the SMC range are vulnerable
Windows '95All of 'emCrashOnce again, the same problem as NT 3.51 and NT 4.0. '95 can be killed quite effectively by sending a large ping (not receiving). Try the instructions Microsoft have given for NT 3.51, and remember, your mileage may vary - a lot of people have no problems

4.2. Vulnerable operating systems with patches

Operating systemVersionSymptomsComments
AIX3 and 4Operating system dump.Patch Available! The patch for 3.2.5 has been around for a while, so it may already be applied to your system.
Linux<= 2.0.23Spontaneous reboot or kernel panicPatch available!, and supplied here. Kernel 2.0.24 is out, which fixes this. Upgrade now!
Linux1.2.13Reboot, Hang or No effectPatch available!, although this one hasn't been tested. Supplied here
DEC Unix/OSF12.0 and aboveKernel PanicPatch available! and supplied here
OpenVMS for AXPvariousMixed reportsPatch really is available!, as of 15th November (so I've been told). Follow the yellow brick link
OpenVMS for VAXv6.2, UCX v4.0 and othersRebootIt turns out the the one person who managed to crash this was right... OpenVMS for VAX is vulnerable, as DEC have found out. I haven't got any information on this, other than that the vulnerablity is presumably the same as for DEC Ultrix, and that more information can be gained from the CERT Advisory or the Ultrix page linked in column one
HP-UX9.0 to 10.20Crash, Reboot, Hang...Patch available!, follow the link... (it works too...). See also CIAC F-04 for the same information, just officially
Windows NT3.5.1Mixed resultsThe latest word is Microsoft have acknowledged the problem and have released a patch (it seems that sending a bad ping can make NT do some funny things!). Some info just in is that if you do as M*soft says (ping -l 65510 -s 1 ip.address) you can crash NT 3.51. So maybe it is vulnerable after all.
Galacticomm Worldgroup BBS/Terminal Server 1.0, 2.0General Protection FaultYup, this has been fixed too. Patches available for v1 and v2, with version v3 being ping proof. Follow the ol' hyperlink for the scoop. Note that this problem only affects the Galacticomm TCP/IP stack - the Vircom MajorTCP/IP stack is not vulnerable
MkLinux?CrashThere is a guide available on upgrading your kernel to 2.0.27, which will fix the problem
Unisys A seriesTCP/IP pre 32.4 releaseCrashUnisys have informed me that this problem is corrected in the 32.4 and higher A series TCP/IP product. I'm assuming that an upgrade will correct it
Convex OSAll versionsCrashPatch available! Contact the TAC
Solaris (x86)2.5, 2.5.1RebootPatch available. The official patches are #103170-10 for v2.5 and #103631-05 for v2.5.1.
Tandem NSKC30, D20, D42Loses TCP/IPOK, it's not a crash. But (as it has been pointed out to me) if you lose a couple of thousand users who are connected via TCP/IP, that's not safe. For the D20 and C30 machines (I don't know about the D42), sending a ping between 32553 bytes and 32739 bytes kills the TCP/IP process. Pings up to 32759 bytes leave the TCP/IP process running, but unable to function. Greater than 32760 bytes are ignored. Tandem have released some patches, follow the link in column one for more info. Note that patches are not available for all versions.
Digital Ultrix for MIPS/VAXAllVulnerableThis can be killed by a varient on the Ping O'Death under certain conditions (no, I don't know any more than that - DEC aren't telling). DEC have released patches for versions 4.3 on, details of which can be read on the page linked to in column one
Digital UNIX MLS+v3.1a and presumably earlier versions tooVulnerableSee the CERT advisory for details (well, a brief summary)
Digital Firewall, AltaVista Firewall for UNIX?VulnerableSee the CERT advisory
Digital VAX/ELN?VulnerableSee the CERT advisory
IBM Secure Network Gateway Firewall?Presumably the same as AIXSee the CERT advisory for details and APAR numbers.
Irix5.3PanicPatch now available!. Follow the link in column one. This patch also fixes the SYN flood problem. The problem appears to be difficult to reproduce, but if it can be reproduced it will work fairly consistently.
Windows NT4.0CrrrashService Pack 2 seems to fix this problem - please let me know if this is not the case. Well, I've been mailed a lovely little batch file by Mark Rejhon that I have been told will crash NT4 fairly reliably. Marks just sent me a new script with better "documentation", and has informed me that the problem appears to be with sending the pings - as is the case with NT 3.51, NT 4.0 seems to be happier on the receiving end of the ping of death. Either way, its a bug, but unless your machine turns suicidal NT owners have less to worry about (it would seem).
SCO Openserver4.2, 5.0.x and presumably prior versionsVulnerablePatch available. The patch can be downloaded here, and a description of the patch is available here
DEC TOPS-20, TOPS-10AllErrorsThese dinosaurs have a memory leak, caused by sending fragmented packets. Do it too often, and something will go. Fred Wright has patches available for both systems

4.3. Operating systems which just possibly could be vulnerable

This is for systems where only one or two people have had trouble
Operating systemVersionSymptomsComments
NetBSD x86, VAX1.1, 1.1aMixed reportsOne person has managed to crash this, another two have not, and another has not only failed to reproduce this, but has checked the source code and is certain it can't be done! It sounds like the crash was an isolated incident
Apple Network Server?CrashI am unsure of this. I've been told that ANS is based on AIX 4.1.4, which is vulnerable. The AIX patches will stop your machine booting, so don't apply them! There's still no word from Apple on this

4.4. Safe operating systems

Operating systemVersion Tested
Solaris (Sparc)2.3, 2.4, 2.5, 2.5.1
MVS Mainframe with TCP/IP stack from Interlink3.1, 4.1
MVS Mainframe with TCP/IP stack from IBM3.1, 3.2
FreeBSD2.0 and above
BSDI/OS2.01, 2.1
DRS/NX (sparc)7MPlus.9.8
DRS/NX (ICL)7.7.8
UnixWare1.0, 1.1, 2.1
Olivetti SVR42.4.1
NCR Worldmark running MP-RAS SVR42.02, 2.03, 3.0
DG/UX4.11, 5.4
Windows 3.11 with Novell Client-32 / Cisco TCP/IP / MultiNet / WRQ / NCSA / Pathway / MS TCP-32 stack?
Windows '95?
OS/22.11, 3, 4
Banyan VINES6.30, 7.0
Unisys U2200, U6000SVR4 1.4, 1.4.1
Novell Netware4.1
BeOS DR8 network server?
Cray C94, M92Unicos, roo.21 and roo.8
IPR (PC-based router)0.954
MS-DOS w/ Clarkson Telnet?
VM MainframeIBM TCP/IP for VM v2.2
Apple A/UX3.0.2
Sequent Dynix/ptx4.2
Interactive Systems ISC3.0
Bell Plan 9all, presumably
Acorn RISC OSInternet 4.xx and 5.02
NEC UX/4800All
MacOS running Vicom IP softwareAll

4.5. Vulnerable firmware

Ascend Pipeline 130 Router4.6Ci12Mixed resultsTwo people have had no trouble. Another two have caused a reboot. This reportedly crashed while routing packets, not being pinged (pung?) itself!!
Ascend Pipeline 50 Router?RebootTwo people have trouble with this. v4.6Ci17 dies on about the 11th 65510 byte packet. Ascend are unable to reproduce this, and I have had several reports that it's safe, so your mileage may vary
HP Laserjet III, IV?CrashCrashes with "80 Service (01E0)" - It has to be physically turned off and on again.
HP Laserjet V?CrashesAn improvement over the Laserjet III - It prints a diagnostic sheet first, then it dies. Note one person with JetDirect firmware version A.04.09 reported only a lockup for 20 seconds or so, not a crash.
Sun X Terminals?PanicA packet of 50000 bytes will set this off
NCD X Terminals3.3.2, 4.0PanicA packet of 32750 bytes will set this off
HDS Viewstations?CrashNo fix yet, although someone can't reproduce with HDS code v3.0.4, and HDSware/Server code v3.0.1
Tektronix X-Terminal?Lapse of reasonTek have informed me that most versions of their X-Terminals will lock up for 30 seconds or so on reciept of the Ping of Death, but will then come back to life
Microcom HDMS chassis with INC?Momentary lapse of reason Well, not exactly. It stops responding to TCP/IP traffic for 5 minutes or so, and then seems to recover by itself. 5 minutes seems long enough to list it as vulnerable.
Livingston ORU ISDN-Ethernet router3.4.2Lc1HangsA disconnect and a reconnect will remedy this
Digital PEswitch 900TXfirwmare 1.1.0CrashAfter 10 or so rapid oversize packets
3Com (aka ChipCom) Oncore Advanced Ethernet Management Modulesfirmware 4.20-ALapseManagement functions (e.g. OnDemand NCS) were intermittently impacted, but this cleared up after three minutes or so.
Shiva Access port?DiesNo more information so far
ACC Danube routerv8.0.7RebootsACC have tested this and found it safe, but at least two people disagree.

4.6. Vulnerable firmware with patches

Netblazer LS 2PT?RebootEmergency patch available. Contact telebit for details
NetBlazer 40i3.2LockupLocks up completely, have to hard-reset. The latest patch (v3.1 patchlevel 12) fixes the problem. I had an emergency patch available here for download, but this has now been superceded by Telebit's official patch, which you can get through the official channels
Bay Networks Access Node RoutersvariousRebootsBay Networks have fixed this (The reference is Change Request CR24142). The fix can be found in 8.12/rev 14 and 10.01/rev 3. 11.00 also contains the fix.
3Com Netbuilder II router?Reboots3Com now have a fixed version of this. The WA v8.3.0.84 and the FF version are safe
Alantec Powerhub (router/bridge)<v7- pl 9RebootWhen given a broadcast ping of 30000 or greater. I've been told the latest version, version 7- pl 9, is immune.

4.7. Firmware which just possibly could be vulnerable

This is for systems where only one or two people have had trouble
Cisco 4000?CrashOnly two reports on the 4000. One guy had no problems, another has trouble about 70% of the time. The more heavily loaded it is, the higher the chance of a crash. Cisco are sure that the 4000 is OK, which seems reasonable as all their other products hold up well.

4.8. Safe firmware

Ascend Max 4000?
NetBlazer SP3.0 patch 9
NetBlazer Classic2.3 patch 13
3Comm Lanplex & accessbuilder?
3Comm Linkbuilder FMS/IIFlash 3.11, Prom 1.01
Cisco Terminal Server?
Xyplex TS/720V6.0.1S41, Rom 460003
Cisco 7500, 2501, 2503, AGS+?
ELSA LANCOM Multiprotocol router?
Livingston IRX, PortmasterComOS 3.2.1R
IBM6611 router?
Retix 7000 router?
Shiva FastPath VKStart code version 9.2
HP J2410 intelli hub?
Securicor 3Netmodel 2431, firmware 7.2.01
Digital DECnis router 6003.1.6
ACC Colorado8.3.3
ACC Amazon10.0
ACC Tahoe7.3
Digital DEClaser 3500, 5100 printer Ethernet cardv01.38, v03.05
Digital DECconcentrator 900MX FDDI concentratorv3.1.1
Digital RouteAbout EW/MP brouterv1.1.005
Digital DECbrouter 9010.2(5)
Digital DECrepeater 90TM2.0.0
Digital DECswitch 900EF1.5.2
Digital DECbridge 900MX1.5.2
Digital DECserver 300, 700V2.2 BL44-3, V1.1 BL44-1
Nexland 10T(12/24) 12/24-port SNMD-managed hub1.20
ACS 4105 remote bridge2.0
Xerox docuprint 4571XNIC ethernet card v4.14, 4.14N3
Wellfleet routersvarious
Morningstar routerv1.6
Xylogics Terminal Server?
Borderguard 1000, 2000 and Passport systems?
Lexmark Optra Laser Printer?
Chase IOLAN Terminal Server?
Ascend Pipeline 25?
Synoptics (Bay networks) 2813 repeaterv5.1.1
Shiva Access switch4.5
Hirschmann Hubs?
Shiva LanroverOS v4.0, VRAM v5.6.0, HW v1.0
AXIS Printservers, CD-Servers and Camera-ServersAll
XMiNT Xterminal SystemAll

Most of the information on this page was supplied by other people - but the list was getting so long the page was taking all week to load. So they're now listed in the Credits page. Thanks all!