A ping of death (abbreviated "POD") is a type of attack on a computer that involves sending a malformed or otherwise malicious ping to a computer. A ping is normally 56 bytes in size (or 84 bytes when IP header is considered); historically, many computer systems could not handle a ping packet larger than the maximum IP packet size, which is 65,535 bytes. Sending a ping of this size could crash the target computer.
Traditionally, this bug has been relatively easy to exploit. Generally, sending a 65,536 byte ping packet is illegal according to networkingprotocol, but a packet of such a size can be sent if it is fragmented; when the target computer reassembles the packet, a buffer overflowcan occur, which often causes a system crash.
This exploit has affected a wide variety of systems, including Unix, Linux, Mac, Windows, printers, and routers. However, most systems since 1997-1998 have been fixed, so this bug is mostly historical.
In recent years, a different kind of ping attack has become wide-spread - ping flooding simply floods the victim with so much ping traffic that normal traffic fails to reach the system (a basic denial-of-service attack).
[edit]Detailed information
As defined in RFC 791, the maximum packet length of IP is 65,535 (216 − 1) bytes, including the IP header, due to the IP header using 16 bits to describe the total packet length.
The underlying physical layer almost always poses limits to the maximum frame size (See MTU). In Ethernet, this is typically 1500 bytes. In such a case, a large IP packet is split across multiple IP packets (A.K.A IP fragments), so that each IP fragment will match the imposed limit. The receiver of the IP fragments will reassemble them into the complete IP packet, and will continue processing it as usual.
When fragmentation is performed, each IP fragment needs to carry information about which part of the original IP packet it contains. This information is kept in the Fragment Offset field, in the IP header. The field is 13 bits long, and contains the offset of the data in the current IP fragment, in the original IP packet. The offset is given in units of 8 bytes .
This allows a maximum offset 65,528 (
). This means that an IP fragment with the maximum offset should have data no larger than 7 bytes, else it would exceed the limit of the maximum packet length. A malicious user can send an IP fragment with the maximum offset, with data much larger than 8 bytes (as large as the physical layer allows it to be).
When the receiver will assemble all IP fragments, it will end up with an IP packet which is larger than 65,535 bytes. This is likely to overflow memory buffers which the receiver allocated for the packet, and can cause various problems.
As is evident from the description above, the problem has nothing to do with ICMP. It is a problem in the reassembly process of IP fragments, which may contain any type of protocol (TCP, UDP, IGMP, etc).
The fix to the problem is to add checks in the reassembly process. The check for each incoming IP fragment makes sure that the sum of "Fragment Offset" and "Total length" fields in the IP header of each IP fragment is smaller than 65,535. If the sum is larger, then the packet is invalid, and the IP fragment is ignored. This check is performed by some Firewalls, to protect hosts which do not have the bug fixed. Another fix of the problem is using a memory buffer larger than 65,535 bytes for the re-assembly of the packet. (This is essentially a breaking of the specification, since it adds support for packets larger than those allowed.)
No comments:
Post a Comment