Community hub
0 subscribers7 pages, 0 posts
Recent from talks
All channels
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to Ping of death.
Nothing was collected or created yet.
Ping of death
View on Wikipediafrom Wikipedia
A ping of death is a type of cyberattack on a computer system that involves sending a malformed or otherwise malicious ICMP echo request, a message normally associated with the ping utility, to a computer.[1] In this attack, a host sends hundreds of ICMP echo requests with a packet size that is large or illegal to try to take the receiving host offline or to keep it preoccupied responding with replies.[2]
A correctly formed ICMP echo request is typically 56 bytes in size, or 64 bytes when the Internet Control Message Protocol (ICMP) header is considered, and 84 bytes including Internet Protocol (IP) version 4 header. However, any IPv4 packet may be as large as 65,535 bytes. Some computer systems were never designed to properly handle an ICMP echo request packet larger than the maximum packet size because it violates the Internet Protocol.[3][4] Like other large but well-formed packets, a ping of death is fragmented into groups of 8 octets before transmission. However, when the target computer reassembles the malformed packet, a buffer overflow can occur, causing a system crash and potentially allowing the injection of malicious code.
In early implementations of TCP/IP, this bug is easy to exploit and can affect a wide variety of systems, including Unix, Linux, Mac, Windows, and peripheral devices. As systems began filtering out pings of death through firewalls and other detection methods, a different kind of ping attack known as ping flooding later appeared, which floods the victim with so many ping requests that normal traffic fails to reach the system (a basic denial-of-service attack).
The ping of death attack has been largely neutralized by advancements in technology. Devices produced after 1998 include defenses against such attacks,[specify] rendering them resilient to this specific threat. However, in a notable development, a variant targeting IPv6 packets on Windows systems was identified, leading Microsoft to release a patch in mid-2013.[5]
Detailed information
[edit] | This section needs additional citations for verification. (April 2024) |
The maximum packet length of an IPv4 packet including the IP header is 65,535 (216 − 1) bytes,[3] a limitation presented by the use of a 16-bit wide IP header field that describes the total packet length.
The underlying data link 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 (also known as 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 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 of 65,528 ((213 − 1) × 8). Then when adding 20 bytes of IP header, the maximum will be 65,548 bytes, which exceeds the maximum frame size. This means that an IP fragment with the maximum offset should have data no larger than 7 bytes, or else it would exceed the limit of the maximum packet length. A malicious user can send an IP fragment with the maximum offset and with much more data than 8 bytes (as large as the physical layer allows it to be).
When the receiver assembles all IP fragments, it will end up with an IP packet which is larger than 65,535 bytes. This may possibly overflow memory buffers that 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, which is used only as payload, big enough to exploit the problem. It is a problem in the reassembly process of IP fragments, which may contain any type of protocol (TCP, UDP, IGMP, etc.).
The correction of 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 or equal to 65,535. If the sum is greater, then the packet is invalid, and the IP fragment is ignored. This check is performed by some firewalls, to protect hosts that do not have the bug fixed. Another fix for 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.)
Ping of death in IPv6
[edit]In 2013, an IPv6 version of the ping of death vulnerability was discovered in Microsoft Windows. Windows TCP/IP stack did not handle memory allocation correctly when processing incoming malformed ICMPv6 packets, which could cause remote denial of service. This vulnerability was fixed in MS13-065 in August 2013.[6][7] The CVE-ID for this vulnerability is CVE-2013-3183.[8] In 2020, another bug (CVE-2020-16898) in ICMPv6 was found around Router Advertisement, which could even lead to remote code execution.[9]
See also
[edit]References
[edit]- ^ Abdollahi, Asrin; Fathi, Mohammad (2020-01-23). "An Intrusion Detection System on Ping of Death Attacks in IoT Networks". Wireless Personal Communications. 112 (4): 2057–2070. doi:10.1007/s11277-020-07139-y. ISSN 0929-6212. S2CID 213121777.
- ^ Elleithy, Khaled; Blagovic, Drazen; Cheng, Wang; Sideleau, Paul (2005-01-01). "Denial of Service Attack Techniques: Analysis, Implementation and Comparison". School of Computer Science & Engineering Faculty Publications.
- ^ a b J. Postel, ed. (September 1981). INTERNET PROTOCOL - DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION. IETF. doi:10.17487/RFC0791. STD 5. RFC 791. IEN 128, 123, 111, 80, 54, 44, 41, 28, 26. Internet Standard 5. Obsoletes RFC 760. Updated by RFC 1349, 2474 and 6864.
- ^ Erickson, Jon (2008). HACKING the art of exploitation (2nd ed.). San Francisco: NoStarch Press. p. 256. ISBN 978-1-59327-144-2.
- ^ "Ping of death DDoS attack". Cloudflare.
- ^ "Microsoft Security Bulletin MS13-065 – Important". Microsoft. August 13, 2013. Retrieved February 25, 2017.
- ^ Jackson, Joab (Aug 13, 2013). "Microsoft Patch Tuesday: The Ping of Death returns, IPv6-style". Retrieved February 25, 2017.
- ^ "CVE - CVE-2013-3183". The MITRE Corporation. Retrieved February 25, 2017.
- ^ "CVE-2020-16898 - Windows TCP/IP Remote Code Execution Vulnerability". Microsoft. October 13, 2020. Retrieved October 14, 2020.
External links
[edit]- The Ping o' Death Page at the Wayback Machine (archived December 6, 1998)
- Ping of death at Insecure.Org
Ping of death
View on Grokipediafrom Grokipedia
Background
ICMP and Ping Protocol
The Internet Control Message Protocol (ICMP) is a supporting protocol integral to the Internet Protocol (IP), designed primarily for error reporting, diagnostics, and control functions within IP networks.[5] As specified in RFC 792, ICMP operates at the network layer alongside IP and is implemented by every IP module to provide feedback on communication problems, such as unreachable destinations or routing issues, without ensuring message delivery reliability.[5] In IPv4 environments, ICMP messages are encapsulated within IP datagrams, using the IP header to route them, and serve as a mechanism for hosts and gateways to exchange diagnostic information.[5] A key application of ICMP is the ping utility, which utilizes ICMP Echo Request messages (type 8, code 0) to test network reachability and measure round-trip time (RTT) between devices.[5] When a host sends an Echo Request, the target device responds with an Echo Reply message (type 0, code 0), echoing back the original data payload to confirm connectivity.[5] This exchange allows network administrators to verify if a remote host is operational and to assess latency, with the RTT calculated as the time from sending the request to receiving the reply.[5] Identifiers and sequence numbers in the messages help match replies to specific requests, especially in scenarios with multiple concurrent pings.[5] The standard structure of an ICMP message consists of an 8-byte header followed by optional data.[5] The header includes a 1-byte Type field (e.g., 8 for Echo Request), a 1-byte Code field (typically 0 for echo messages), and a 2-byte Checksum for error detection, computed using one's complement sum over the header and data.[5] The remaining 4 bytes in the header for echo messages contain an Identifier and Sequence Number, while the optional data payload—often arbitrary bytes for testing—mirrors the request in the reply.[5] Encapsulated in an IPv4 datagram, ICMP messages adhere to the protocol's maximum size limit of 65,535 bytes, though typical ping packets are much smaller, such as 64 bytes including headers, to facilitate quick diagnostics.[6] In network troubleshooting, ping and other ICMP messages enable systematic diagnostics, such as detecting host availability, tracing path issues via combined tools like traceroute (which uses ICMP Time Exceeded messages), or reporting congestion through Source Quench messages.[5] These functions support efficient IP network management in IPv4 deployments, where ICMP provides essential visibility without altering the core datagram delivery process.[5] IP fragmentation, a related IP mechanism, handles oversized datagrams by splitting them for transmission, ensuring compatibility with ICMP's diagnostic role.[6]IP Fragmentation Basics
In IPv4, the maximum transmission unit (MTU) defines the largest packet size that can be transmitted over a network link without fragmentation, with Ethernet networks typically supporting an MTU of 1,500 bytes.[7] When an originating host needs to send a datagram larger than the MTU of an intermediate link, the router or host fragments it into smaller pieces to ensure transmission across diverse network segments.[8] This process allows IPv4 to handle variable-sized datagrams efficiently in heterogeneous environments, such as when ICMP echo packets exceed the path MTU.[8] Key fields in the IPv4 header facilitate fragmentation and reassembly: the Identification field (16 bits) assigns a unique value to match all fragments of the same datagram; the Fragment Offset field (13 bits) specifies the position of the fragment in the original datagram, measured in 8-byte units; and the More Fragments (MF) flag (1 bit) indicates whether additional fragments follow, with MF set to 0 in the last fragment.[8] These fields enable routers to split datagrams and destinations to reconstruct them accurately. The total length of the reassembled datagram cannot exceed 65,535 bytes, as defined by the 16-bit Total Length field in the IP header.[8] At the destination host, reassembly involves collecting all fragments with matching Identification values, ordering them by Fragment Offset, and combining their data payloads while verifying the MF flags and total length.[8] If reassembly fails—such as due to a missing fragment—the entire datagram is discarded, and an ICMP Time Exceeded message (type 11, code 1) may be sent to the source. For cases where fragmentation is required but the Don't Fragment (DF) bit is set in the original datagram, intermediate routers discard the packet and return an ICMP Destination Unreachable message with code 4 (Fragmentation Needed and DF Set), including the MTU of the restricting link to aid path MTU discovery.Attack Mechanism
Packet Construction and Transmission
In the IPv4 ping of death attack, the attacker begins by constructing an ICMP echo request packet designed to exceed the protocol's maximum allowable size of 65,535 bytes for the total IP datagram, often setting the payload to 65,536 bytes or more to induce an overflow upon reassembly.[9][10] This oversized packet includes the standard ICMP echo request structure, consisting of a type field set to 8 (echo request), a code field of 0, a checksum, an identifier, a sequence number, and the oversized data payload.[10] To generate such packets, attackers employ specialized tools like hping, a command-line packet generator capable of crafting custom ICMP packets with arbitrary data sizes, or custom scripts that specify large payload lengths beyond typical ping utilities' defaults.[11][10] These tools allow the attacker to bypass local maximum transmission unit (MTU) limits—typically 1,500 bytes for Ethernet—by instructing the sending system's IP stack to create the oversized packet, which is then automatically fragmented before transmission.[12] During transmission, the source system's IP stack or an intervening router fragments the oversized packet into smaller segments compliant with the network's MTU, ensuring that the sum of the data portions across all fragments exceeds the 65,535-byte IP maximum while each individual fragment remains valid.[9][12] For instance, the IP headers of these fragments share an identical identification field to associate them as parts of the same original packet; a common configuration includes an initial fragment with offset 0 and subsequent fragments with progressively higher offsets, such as a final fragment at offset 65,528 bytes (maximum fragment offset value) carrying more than 7 bytes of data, resulting in an indicated total reassembled size exceeding 65,535 bytes.[13] The fragments are then transmitted to the target via standard IP routing protocols, potentially arriving out of order, with duplicates, or incompletely due to network conditions, all while maintaining the malicious intent encoded in their collective size.[14][10]Reassembly and Overflow Exploitation
When a target system receives the fragmented IP packets comprising an oversized ICMP Echo Request, its IP stack initiates the reassembly process to reconstruct the original datagram. The stack allocates a reassembly buffer whose size is determined by summing the lengths of the incoming fragments and accounting for their offset positions, without initially validating the total against the IPv4 protocol's 65,535-byte maximum transmission unit limit. This allocation can lead to a buffer overflow if the crafted fragments indicate a total reconstructed packet size exceeding the allocated buffer's capacity or the protocol's bounds, as the data from overlapping or extended fragments is copied into contiguous kernel memory. In vulnerable implementations, such as certain early versions of Windows and Unix-like operating systems, this results in memory corruption beyond the buffer's end, potentially overwriting adjacent data structures in the kernel space.[1] The overflow typically triggers unhandled exceptions, causing effects like system crashes, freezes, or complete denial of service; for instance, in Unix-like systems, it may induce a segmentation fault that halts the kernel's operation, rendering the machine unresponsive until reboot. These disruptions stem from the failure to contain the excessive data within safe memory boundaries during the finalization of reassembly.[15] The vulnerability arises because early IP stack implementations omitted rigorous bounds checking on the aggregate reassembly size, assuming fragments would conform to protocol specifications without verifying the total against the 65,535-byte limit prior to buffer population. This oversight allowed malformed inputs to evade detection until the overflow manifested during data handling.[1] The following pseudocode illustrates a simplified vulnerable reassembly routine in an affected IP stack:initialize buffer[65536]; // Fixed-size buffer assuming max IP size
total_size = 0;
for each incoming_fragment {
offset = fragment.offset;
length = fragment.length;
total_size += length; // Accumulate without bounds check
copy fragment.data to buffer[offset]; // Overwrite if overlapping
}
if (total_size > 0) { // No check for total_size > 65535
process_reassembled_packet(buffer, total_size); // Overflow if total_size > buffer capacity
}
initialize buffer[65536]; // Fixed-size buffer assuming max IP size
total_size = 0;
for each incoming_fragment {
offset = fragment.offset;
length = fragment.length;
total_size += length; // Accumulate without bounds check
copy fragment.data to buffer[offset]; // Overwrite if overlapping
}
if (total_size > 0) { // No check for total_size > 65535
process_reassembled_packet(buffer, total_size); // Overflow if total_size > buffer capacity
}
if (total_size > [65535](/page/65,535)) discard_fragments();, which was missing in susceptible systems.
History and Impact
Discovery and Early Incidents
The Ping of Death vulnerability was first publicly documented in October 1996, when security researcher Malachi Kenney launched a dedicated webpage detailing the exploit, which involved sending oversized IP packets via the ping utility to cause remote system crashes.[16] This proof-of-concept demonstrated that fragmented ICMP echo request packets exceeding the maximum IP packet size of 65,535 bytes could trigger buffer overflows during reassembly, leading to denial-of-service effects.[16] Early testing revealed the issue affected a wide range of systems, with successful crashes observed over long distances, such as from Berkeley, California, to London, England.[16] Widespread awareness grew through security communities in late 1996, with discussions on mailing lists like Bugtraq reporting Linux kernel vulnerabilities exploitable via ping as early as October 21, 1996.[17] The Linux community responded rapidly, releasing a kernel patch within approximately two and a half hours of the initial report.[16] Initial incidents targeted early internet hosts, including university networks, causing temporary outages, system freezes, and reboots on vulnerable machines running Unix variants and other operating systems. The CERT Coordination Center formalized the threat in Advisory CA-1996-26, issued on December 18, 1996, warning of denial-of-service attacks via oversized ping datagrams that could crash, freeze, or reboot affected systems.[18] The advisory highlighted reports from multiple vendors, including Digital, Sun Microsystems, and IBM, confirming impacts on Windows, Macintosh, and Unix platforms.[18] Media coverage in hacker publications, such as Phrack magazine's discussions of denial-of-service techniques, and ARPANET-related security forums further amplified the issue by late 1996.[19] Vendors began issuing patches shortly after, with widespread fixes available by early 1997, marking the transition from discovery to mitigation.Affected Systems and Vulnerabilities
The ping of death vulnerability stems from a lack of proper checks on the size of reassembled IP packets in many TCP/IP stack implementations, allowing oversized fragmented ICMP echo request packets to exceed the maximum IP datagram size of 65,535 bytes and trigger buffer overflows during reassembly. This flaw enabled denial-of-service (DoS) conditions by causing systems to crash, freeze, or reboot unpredictably when processing the malicious packets.[16] Among operating systems, early Microsoft Windows versions such as Windows 95 and Windows NT were highly susceptible, often resulting in hard locks or kernel panics upon packet reassembly due to inadequate buffer size validation in their IP stacks.[16] Unix variants exhibited similar issues; for instance, Sun Microsystems' Solaris 2.5 (and earlier releases like 2.3 to 2.4) would panic during reassembly attempts, halting the kernel and requiring manual reboots. Early Linux kernels in the 2.0.x series were also vulnerable, leading to system crashes from the same overflow exploitation, though later kernels implemented fixes to discard oversized fragments.[16] Other impacted Unix systems included Digital UNIX 3.0/3.2/4.0, ULTRIX 4.3-4.5, IBM AIX 3.2/4.1/4.2, and SCO OpenServer 5.0.0/5.0.2, where failure modes typically involved kernel panics or resource exhaustion. Network devices faced comparable risks from deficient fragment processing logic. Cisco routers running IOS versions 10.x and earlier could crash when attempting to reassemble oversized IP fragments, disrupting routing tables and forwarding operations across connected networks. Early firewalls, including IBM's Secured Network Gateway (SNG) V2.1/V2.2, would similarly fail during fragment handling, resulting in service denial and potential exposure of protected segments to further attacks. In 1996, this vulnerability posed widespread DoS risks to the burgeoning Internet, impacting a vast array of connected hosts and devices as reported by the CERT Coordination Center, with exploits rapidly circulating and necessitating urgent vendor patches across the ecosystem. Systems that enforced strict maximum transmission unit (MTU) limits or discarded invalid fragments were less prone; for example, post-patched Berkeley Software Distribution (BSD) variants, such as BSD/OS 2.1, incorporated reassembly safeguards that prevented exploitation.Mitigation Strategies
Software Patches and Updates
Microsoft released specific patches for the ping of death vulnerability in late 1996, addressing affected systems including Windows NT 4.0 and Windows 95. These updates introduced reassembly bounds checks in the IP stack to prevent buffer overflows from malformed oversized packets, ensuring that fragmented ICMP echoes exceeding the 65,535-byte limit were discarded before processing.[16][20] For Windows NT 4.0, the patch was issued as a hotfix shortly after the vulnerability's public disclosure, while Windows 95 received a similar update integrated into subsequent releases like OSR2.1, which included enhanced packet validation.[16] In Unix and Linux environments, kernel-level fixes were rapidly deployed through updates that enforced strict IP length validation prior to buffer allocation during reassembly. For instance, the Linux kernel 2.0.24, released in December 1996, incorporated patches to handle oversized fragments by rejecting packets where the total reassembled data surpassed 65,535 bytes, averting kernel panics or reboots.[16] The Linux 2.1.x development series, active in late 1996, integrated similar protections natively, with code changes in the IP fragmentation routines to compute and verify the aggregate length early in the process.[16] Comparable updates were provided for other Unix variants, such as Solaris 2.5 and HP-UX 10.x, focusing on discarding invalid fragments at the network layer. These patches were guided by the CERT advisory CA-1996-26, which coordinated vendor responses to the vulnerability.[1] The general approach across affected software involved modifications to the IP protocol stack, exemplified by pseudocode that checks the sum of fragment data lengths against the maximum IP packet size:if (total_length = sum(fragment_lengths) > 65535) {
discard_packet();
log_anomaly();
} else {
proceed_to_reassembly();
}
if (total_length = sum(fragment_lengths) > 65535) {
discard_packet();
log_anomaly();
} else {
proceed_to_reassembly();
}
ping -s 65510 target, which on patched systems would either truncate the packet or elicit no crash, confirming the fixes' efficacy without disrupting normal operations.[16] These updates effectively neutralized the vulnerability in IPv4 implementations by the end of 1996, rendering the original ping of death obsolete on compliant systems.
Network-Level Defenses
Network-level defenses against the ping of death attack focus on perimeter configurations that filter or restrict malicious ICMP traffic before it reaches endpoint systems, thereby preventing packet reassembly and potential buffer overflows. These measures, implemented on firewalls, routers, and intrusion detection systems, provide a first line of protection by inspecting and dropping anomalous packets at the network edge.[10] Firewalls can be configured with rules to block inbound ICMP echo requests or fragments, effectively stopping oversized ping packets from propagating. For instance, using iptables on Linux-based firewalls, administrators can drop ICMP echo requests exceeding typical packet sizes, such as:iptables -A INPUT -p icmp --icmp-type echo-request -m [length](/page/Length) --length 1500: -j DROP. This rule targets non-fragmented packets larger than the standard Ethernet MTU (1500 bytes). For fragmentation-based exploits like ping of death, additional rules to block ICMP fragments are recommended, such as iptables -A INPUT -p icmp -f -j DROP. Similarly, blocking all incoming ICMP traffic via iptables -A INPUT -p icmp -j DROP prevents pings from reaching internal hosts, though it may hinder legitimate diagnostics.[21][22]
On routers, access control lists (ACLs) enable precise filtering of ICMP traffic to counter ping of death attempts. Cisco routers, for example, support extended ACLs to deny fragmented ICMP packets, as in: access-list 101 deny icmp any any fragment, which is applied to inbound interfaces to drop such traffic early in the path. Additionally, committed access rate (CAR) policies can rate-limit ICMP echo requests, such as limiting to 1000 bits per second with burst allowance, using commands like rate-limit input access-group 101 1000 1500 500 conform-action transmit exceed-action drop. These configurations ensure oversized or excessive ICMP does not overwhelm the network.[23]
Intrusion detection systems like Snort, introduced in 1998, incorporate signature-based rules to identify and alert on ping of death patterns, such as oversized ICMP echo requests. An example Snort rule for detection is: alert icmp any any -> any any (msg:"Ping of Death Detected"; dsize>1000; itype:8; sid:1000001;), which triggers on echo requests (type 8) exceeding 1000 bytes, allowing network administrators to block or log such anomalies in real-time. Early Snort deployments used similar rules to match fragmented or malformed ICMP, integrating with prevention modes for automated dropping.[24]
Best practices for network-level security include disabling ICMP echo responses on public-facing interfaces to reduce exposure, as routers and firewalls can be configured to ignore or silently drop such requests without alerting attackers. Rate limiting ICMP traffic further enhances resilience; for instance, Cisco's Control Plane Policing (CoPP) can cap ICMP at low thresholds, like 10 packets per second, using policy maps to protect routing infrastructure from floods. These approaches complement software patches by addressing threats externally.[22][23]
By intercepting malicious packets prior to reassembly, these defenses significantly reduce endpoint load and prevent exploitation.[10]