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