This is a guest post from Antonios Atlasis.
Taking the chance from a discussion on the IPv6 hacker’s mailing list and the freshly proposed draft RFC regarding the deprecation of the generation of IPv6 Atomic Fragments, I decided to test very quickly what is the current status related with the latest and some of the most poplar Operating Systems (OS) status (whether they send Atomic Fragments in response to Packet Too Big messages, or not). The motivation behind this was to check which one of them is potentially vulnerable to the DoS attack using the technique described in the above proposed RFC and taking it for granted that Atomic Fragments are blocked in the real world (but more about this, in another blogpost in the near future).
To this end, I checked:
- Fedora 20,
- Centos 6.5
- FreeBSD 10
- Kali 1.0.8 (Debian based)
- OpenBSD 5.5
- Windows 7.1
From the aforementioned OS, the last two (OpenBSD 5.5 and Windows 7.1 ) enable by default private/temporary IPv6 addresses.
Test 1:
Initially, when I sent ICMPv6 Packet Too Big (PTB) messages with MTU=1280 bytes and encapsulating an ICMPv6 Echo Request message (pretending that this PTB is a response to an ICMPv6 Echo Request sent by the victim) and then I pinged from the tested OS the sender of the PTB messages, all but Windows and OpenBSD included IPv6 Fragment Extension Headers (with offset=0 and M bit =0, that is, Atomic Fragments) in their messages. The exception of Windows and OpenBSD happened because these two systems used their private/temporary addresses as a source address.
Test 2:
So, I repeated the test but this time, I sent the PTB messages to the private/temporary addresses of the last two OS. This time, Windows used Atomic Fragments too in order to send their ICMPv6 Echo Request messages. OpenBSD still “refused” to use Atomic Fragments. Great, I thought!
Some observations before I continue: It took about 22-25 secs for Fedora to recover (not that bad), Kali about 6 minutes, Windows about 8 minutes, while Centos 6.5 (which runs a kernel of the 2.6.32 family, but it is a red-hat clone, a widely used enterprise system) and FreeBSD 10 (to my disappointment) did not recover even after about half an hour (and I must admit that I did not have the patience to wait any longer).
Test 3:
However, an attacker may not (?) know these private/temporary addresses, right? So, in my third testing scenario I sent PTB messages to the non-private/temporary addresses and ICMPv6 Echo Request messages from the sender of the PTB messages to the targets to check which addresses are used as source addresses in their response (I remind you that in my previous two tests I pinged from the targets the sender of the PTB). Well, both Windows and OpenBSD, although they replied by using as a source address the non private/temporary ones, they did not use Atomic Fragments for their responses. Which is good, actually, isn’t it?
Test 4:
Now, the question here is, what if we send an ICMPv6 PTB to the non-private/temporary addresses of the targets (assuming that it is a spoofed message) encapsulating an ICMPv6 Echo Request (that is, supposing that it is a response to an ICMPv6 Echo request message sent from the target) and then, to request another service from the targets (e.g. TCP port 22, or port 445) using as source address the previously spoofed one. Well, the results showed that OpenBSD and Windows did not use Atomic Fragments to their responses, as we would rather expect from the results of the previous scenario, while all the others did. So, these last OS (Linux, FreeBSD) do not test in which of their messages the PTB is sent in response too.
Test 5:
Now, what if we enable the IPv6 Privacy Extension headers to the other OS. I tried it against Fedora and then I repeated the test 3 above. After enabling them and rebooting, to my disappointment, it still used IPv6 Atomic Fragments.
To sum up:
- OpenBSD does not include Atomic Fragments in response to ICMPv6 Packet Too Big messages.
- Windows (7.1) do not include Atomic Fragments either, as long as this PTB message is not sent directly to their temporary address.
- All the other OS do send Atomic Fragments. From them:
- Fedora recovers really fast.
- Centos 6.5 and FreeBSD need a really long time (wake up, guys)!
pcap files are available to those who are interested.
Best
Antonios