IP fragmentation is an ancient mechanism that nevertheless yields surprising attacks in modern days, due to its complexity.
This post explains CVE-2018-8493, an interesting vulnerability that I’ve recently found and was patched in the latest Patch Tuesday.
INTRODUCTION
The IP protocol suite supports fragmentation in order to transport packets longer than a link’s MTU. The design relies on an identification field (“IP ID”), such that all fragments that belong to the same packet will have the same IP ID.
(Ipv4 only uses a 15 bit Identification field, whereas Ipv6 uses 31 bits which appears on an IPv6 optional header)
In 2003 it was shown that this design was vulnerable, as (in a naïve implementation, a global counter) an attacker could blindly intercept or discard packets. Later, more mature demonstrations surfaced (i.e this one).
Before that, predicting this identification field allowed attackers to scan networks without disclosing the compromised node (“idle scan”).
An excerpt from this master thesis shows the state of the art (2013) with major OSs’ implementations for the assignment method of IP ID:
Notice how Windows and non-BSD Linux are marked “Global” for a global counter. Not too great…
SO THEY SOLVED IT!
Around that time Microsoft started generating the IP ID randomly, uniquely per IP-PATH (=src,dst tuple).
They chosen the Toeplitz hash for this task (with a random 40 bytes key). Why? Because they were implementing Receive-Side-Scaling as hinted by the “Rss” prefix on the used functions. While mixing performance and security is not always the best idea, this design could in principle still be safe… but we’ll see.
IMPLEMENTATION
IP ID is calculated in the following way: