It's the Ping o' Death Page!

How to crash your operating system!

1. The Problem

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

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

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

ping -l 65510 your.host.ip.address

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

• Now, courtesy Bill Fenner, those of us without access to '95 or NT can crash machines too - go here for the source code to an evil implementation of ping.
• Apparently, according to Volker Ossenkopf, the ping command on Linux can be rebuilt with a higher package size limit in the ping source, and used to whack machines too. Remember, Linux Ping must be run as root. Note - I've tried this and can't make it work... Volker did it with Kernel 1.3.84, so maybe things have changed since then
• I've also been given a pointer by Darren Reed to this package, which is "a generic tool for testing the robustness of IP stacks. It includes tests which try to exploit many different problems." It sounds like it would probably identify this ping problem, plus any others lurking in your networking code.
• If you're having trouble reproducing this, try loading the machine up. Although it's hard to tell, it seems that a nearly idle machine is more likely to withstand the "Ping O'Death" than one which is busy/swapping/otherwise earning it's living. This is possibly due to a memory overflow being more likely to hit something important if the machine is busy... also, I've been told the maximum size packet from Windows '95 is 65527, which is 20 bytes over the legal limit. This may produce more spectacular results than a 65510 ping.
• And as an aside... from Nick Bastin...
  Unfortunately, while Irix 6.2 has been patched to keep the 64k ping crash from occuring on its servers, it now has the ability to send such a ping, even as a flood...apparently this was some kind of retribution from the programmers so that owners of Irix 5.3 could kill the people that killed them...<g>
  

3. How to prevent people from breaking your 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).

• Thanks to Alastair Young, we have some information on how to block the evil ping using Firewall-1. Follow this link for details.

4. The affected systems

4.1. Vulnerable operating systems without patches

4.2. Vulnerable operating systems with patches

4.3. Operating systems which just possibly could be vulnerable

4.4. Safe operating systems

4.5. Vulnerable firmware

4.6. Vulnerable firmware with patches

4.7. Firmware which just possibly could be vulnerable

4.8. Safe firmware