IP fragmentation attack refers to a vulnerability in the reorganizing of computer programs.
1. Why does IP fragmentation exist?
The link layer has a characteristic called the Maximum Transmission Unit (MTU), which limits the maximum length of data frames. Each network type has an upper limit. Ethernet’s MTU is 1500, which you can check using the netstat -i command. If the IP layer has a packet to send and the length of the packet exceeds the MTU, the IP layer has to perform fragmentation, ensuring each fragment’s length is less than or equal to the MTU.
Suppose you want to transmit a UDP packet with Ethernet’s MTU at 1500 bytes. Generally, an IP header is 20 bytes, and a UDP header is 8 bytes, leaving a payload for data of 1500-20-8=1472 bytes. If the data exceeds 1472 bytes, fragmentation will occur.
IP headers contain information necessary for fragmentation and reassembly:
Identification R DF MF fragment Offset
Identification: The unique value assigned by the sender to identify an IP packet, duplicated for each fragment.
R: Reserved, not used.
DF: Don’t Fragment flag, when set to 1, prevents fragmentation of the datagram by the IP layer.
MF: More Fragments flag, set to 1 for every fragment except the last.
Fragment Offset: The position of the fragment in the original packet, multiplied by 8 to get the byte offset.
Additionally, once a datagram is fragmented, each fragment’s total length is set to its fragment length.
Each IP fragment is routed separately and reassembled by the IP layer at the destination host. Rest assured, the header data accurately completes fragment reassembly. Yet you may ask, if reassembly is possible, how does a fragment attack arise?
2. IP Fragmentation Attack
The IP header has two bytes indicating the complete IP packet length, thus a maximum of 0xFFFF, which equals 65535 bytes. Intentionally sending fragments with a total length exceeding 65535 bytes can cause issues with older system kernels, leading to crashes or denial of service. Moreover, with carefully crafted offsets between fragments, some systems might malfunction and crash. The vulnerability root is in the reassembly algorithm.
Let’s break down some famous fragment attack programs to understand how IP fragments can be maliciously crafted to attack systems.
3. ping o’ death
Ping o’ death leverages the ICMP protocol for a fragmentation attack. The attacker sends an Echo Request packet exceeding 65535 bytes, causing the target host to overflow the preallocated 65535-byte buffer during reassembly, resulting in a crash or freeze. Ping just sends ICMP Echo Request packets, right? Let’s try an attack! Disregarding the IP and ICMP header lengths, having more data is beneficial, let’s go with 65535, sending a packet:
# ping -c 1 -s 65535 192.168.0.1
Error: packet size 65535 is too large. Maximum is 65507
No luck, it seems Linux’s built-in ping doesn’t allow malicious actions. 🙁
65507 is calculated as: 65535-20-8=65507. Win2K’s ping is more restrictive, only allowing data of size 65500. So you have to find another program to send packets, but modern operating systems already address this flaw, so keep reading this article.
As an aside, recall the “patriotic hackers” of 1999 (“the predecessors of the Red Guests”) inciting netizens to ping an American site simultaneously, attempting to crash the remote server with ping. This was a Pingflood attack, using vast Echo Request packets to slow host response and block target networks, differing from the ping o’ death.
4. jolt2
Jolt2.c sends ICMP/UDP IP fragments in an infinite loop, locking up Windows systems. I tested unpatched Windows 2000, and CPU utilization spiked to 100%, rendering the mouse unusable.
We captured packets using Snort via ICMP and UDP protocols.
ICMP packet sent:
01/07-15:33:26.974096 192.168.0.9 -> 192.168.0.1
ICMP TTL:255 TOS:0x0 ID:1109 IpLen:20 DgmLen:29
Frag Offset: 0x1FFE Frag Size: 0x9
08 00 00 00 00 00 00 00 00 ………
UDP packet sent:
01/10-14:21:00.298282 192.168.0.9 -> 192.168.0.1
UDP TTL:255 TOS:0x0 ID:1109 IpLen:20 DgmLen:29
Frag Offset: 0x1FFE Frag Size: 0x9
04 D3 04 D2 00 09 00 00 61 ……..a
From these results:
* MF flag = 0, indicating the final fragment.
* Offset is 0x1FFE, calculating reassembled length as (0x1FFE * 8) + 29 = 65549 >65535, overflowing.
* IP packet ID is 1109, useful for IDS signature detection.
* ICMP packet:
Type 8, Code 0, indicating Echo Request;
Checksum is 0x0000, as the program didn’t compute it, making the ICMP packet invalid.
* UDP packet:
Destination port is user-specified in command parameters;
Source port results from OR with 1235 to the destination port;
Checksum is 0x0000, similar to ICMP, invalid UDP.
The payload consists of just one character ‘a’.
In jolt2.c, source IP address forgery is possible, though the source code doesn’t assign the user’s intended spoofing IP to src_addr, possibly intentionally by the author.
Jolt2 has significant impact by constantly sending large offset packets, not only deadlocking unpatched Windows systems but also increasing network traffic substantially. Jolt2 has been used to simulate network traffic and test IDS efficiency under high traffic loads, leveraging this characteristic.
5. teardrop
Teardrop is straightforward, sending two UDP packets to crash certain Linux kernels. Effect captured by Snort:
First one:
01/08-11:42:21.985853 192.168.0.9 -> 192.168.0.1
UDP TTL:64 TOS:0x0 ID:242 IpLen:20 DgmLen:56 MF
Frag Offset: 0x0 Frag Size: 0x24
A0 A8 86 C7 00 24 00 00 00 00 00 00 00 00 00 00
…..$……….
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
…………….
00 00 00 00 ….
* MF=1, offset=0, the first fragmented IP packet.
* Structure:
IP UDP Data
Second one:
01/08-11:42:21.985853 192.168.0.9 -> 192.168.0.1
UDP TTL:64 TOS:0x0 ID:242 IpLen:20 DgmLen:24
Frag Offset: 0x3 Frag Size: 0x4
A0 A8 86 C7 ….
* MF=0, offset=0x3, offset byte is 0x3 * 8 = 24, final fragment.
* Structure:
IP Data
If you modify the source code, the offset for the second fragment can be 0x4, making the byte offset 0x4 * 8 = 32.
The diagram below shows the reassembly process, corresponding to offsets 24 and 32:
IP UDP Data
Data
Data
This shows that the second fragment’s offset is less than where the first finishes, and including the Data of the second fragment doesn’t exceed the end of the first, causing an overlap. Older Linux kernels (1.x – 2.0.x) struggled with this overlap during reassembly; WinNT/95 would crash upon receiving 10 to 50 teardrop fragments. You can read the teardrop.c source code to learn how to craft and send such packets.
6. How to prevent IP fragmentation attacks
* Ensure Windows systems have the latest Service Pack, as the most recent Linux kernels are unaffected.
* If possible, block fragmentation packets at the network boundary or use IPTABLES to limit the number of fragments allowed per second.
* If the firewall can reassemble fragments, ensure its algorithm is sound, as a DoS attack can affect the entire network.
* For Win2K systems, customize the IP security policy to enable “fragment inspection.”