Fragmentation Considered
Vulnerable
Yossi Gilad & Amir Herzberg
Computer Science Department, Bar Ilan University
Overview




IP fragmentation recap
`Easy case’ fragment miss-association attacks
Fragmentation attacks in tunnels
Conclusions
IP Fragmentation - Recap

Today: attacks on IP fragmentation



The Internet is a diverse network


Blind (spoofing only) attacker
Interception and DoS attacks.
Different Maximal Transmission Units (MTUs) on
different links/nets
What if |long-pkt|>MTU?
LongPkt
Alice
Router
(fragment)
LongPkt
MTU
Router
Router
Defragment
IP Fragmentation - Recap

Solution 1: Path MTU discovery (PMTUd)



Discard oversized pkt, inform sender (via ICMP)
Requires connection
Solution 2: IP fragmentation



‘Break’ long pkt into fragments (|frag|<MTU)
Fragment at: any node (IPv4) / only src (IPv6)
Defragment: only at destination

According to: source, destination, protocol & frag ID
LongPkt
Alice
Router
(fragment)
Long Pkt
Long Pkt
Long Pkt
LongPkt
MTU
Router
Router
Bob
(Defragment)
‘Fragmentation considered Harmful’

IP fragmentation is conceptually easy, but…




Wasteful/harmful [KentMogul87]
Complexities: may arrive late or out of order, overlap
How much storage? How long keep fragments in
cache?
But: still often used


PMTUd often fails (for UDP, no ICMP feedback,…)
Fragmentation is common in UDP and tunneled traffic
[Shannon02]
‘Fragmentation considered Harmful’

Implementation vulnerabilities:



Memory allocation DoS attacks: TearDrop, Rose…
Tiny fragment evasion of firewalls
Specification vulnerabilities:



Fragment cache overflow attack [KPS03]
Zalewski (2003) notes that fragmented TCP traffic
can be vulnerable to (blind) TCP injections
Fragment mis-association attack [M04,rfc4963]
Fragment Misassociation Attack
MTU=
1500B
HDR+1480B
(ID=x)
MTU=
1000B
SrcIP=Alice, Dst=Bob,
ID=1, Offset=980, MF=0
SrcIP=Alice, Dst=Bob,
ID=2, Offset=980, MF=0
….
SrcIP=Alice, Dst=Bob,
HDR+980B, ID=x, offset=0 ID=b, Offset=980, MF=0
HDR+500B, ID=x, offset=980
Fragment mis-association attack:
Send fake 2nd frag with same ID…
(if x≤b)
(stays in cache
till timeout or
kills next ID=x frg)
But,
|cache|<<#frags
(drop%<<1%)
What if…


Frag mis-association has low drop rate
What if attacker can find the `next’ ID?


Trivial to `kill’ packet (DoS)
Can also `inject’ a fragment

Need to fix checksum


Checksum can be disabled for UDP
How is the IP ID chosen (by the sender)?


Usually a counter – this is specifically
recommended by IPv6 specification
Two main approaches:


Global counter (Windows)
Per-destination counter (Linux)
Sometimes, ID Exposing Is Easy

When the sender uses a global identifier


Just by observing any packet from the sender
When the attacker has a zombie behind the
NAT with the destination

Can also intercept fragments!

Rewrite transport layer header
Sometimes, ID Exposing Is Easy
Intercepting fragments
SrcIP=Alice, DstIP=NAT,
ID=i+1, Offset=1480, MF=0
A. Src-IP=Alice, Dst-IP=NAT,
ID=i+1, Offset=0, MF=1, Dst-port: Bob’s
discarded
B. SrcIP=Alice, DstIP=NAT,
ID=i+1, Offset=1480, MF=0
cached
SrcIP=Alice, DstIP=NAT, ID=i+1,
Offset=0, MF=1, Dst-port: Zombie’s, No chksum
mis-associated
with Alice frag. B
Defrag &
forward to Zombie
Fragment Interception: Results
Results for IP tables based NAT
92.00%
Fragment interception ratio

90.00%
1024 fragments are in
the cache
88.00%
64 fragments are in the
cache
86.00%
84.00%
82.00%
80.00%
0
20
40
60
80
Attacker's bandwidth mbit/sec
100
Other Cases?

Can similar attacks apply when sender
uses per-destination IP-IDs?



Easy: if there is NAT (shown before)
What if there is no NAT?
Yes!

For a tunnel scenario
ID Exposing Attack


Alice and Bob are connected via a tunnel
Main difference from NAT scenario:

Packets `on the Internet’ have a different IP header



Adversarial agent, PuZo, can not `see’ the `Internet’ ID
Improved motivation: fragmentation is common
in tunnels
In talk: Zombie (to receive raw IP packet)

In paper: Puppet (running in sandbox)
ID Exposing Attack


Use packet loss as a side channel to identify the
current ID within the tunnel
We assume no benign traffic or packet loss

Full version shows how to deal with those
ID Exposing Attack – Basic Version
S
GWB
GWA
Begin
Get File
Misassociated
PuZo
ID Exposing Attack – Basic Version
S
GWB
GWA
PuZo
.
.
.
.
.
.
.
.
.
.
.
.
ID Exposing Attack - Meet in the Middle

But… if n is the number of possible identifiers,
this attack requires to send O(n) packets.


216 for IPv4, for 232 IPv6
Revise with meet in the middle technique
ID Exposing Attack - Meet in the Middle


Send n fragments  lay n traps
Narrow the search space to n



Detect loss  assume `ID hit’ (frag. mis-association)
Exhaustive search over all remaining IDs
Reduced number of packets to O( n )

Also feasible for IPv6 (n = 232)
Continual Deny & Expose

Mal has the current ID


Goal: deny fragmented traffic
Main Difficulty: maintain synchronization
with current IP ID

Incremented for every packet (regardless of
arrival/loss)
Continual Deny & Expose

Basic idea: use PuZo to `monitor’ IP ID
progress





Send two sequences of spoofed fragments with
consecutive IDs
Small `gap’ of unset IDs between them
PuZo makes a periodic request for data
Response arrives  ID within the gap
Send the next sequence
Continual Deny & Expose - Results
Success depends on the number of forged
fragment attacker can `cache in’

Usually 64 or no limitation (except cache size, 6500+)
100.00%
99.00%
98.00%
97.00%
Loss Rate

96.00%
95.00%
94.00%
Open source, 256
Open source, 64
Commercial, 256
Commercial, 64
93.00%
92.00%
91.00%
90.00%
0
20
40
60
Attacker's bandwidth Mbit/sec
80
100
Conclusions

Fix IP ID


Need to improve specification of networking
protocols


Add appropriate defenses to network firewalls,
IDS/IPS
Need to develop validation techniques
Further motivation for [Gont11]
Questions?