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).
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.
Continuing the tests, we also decided to check very quickly what is the current situation regarding the acceptance or the rejection of Atomic fragments in the “real world”. Thanks to Rafael Schaefer and the RISC lab at ERNW, we got some first measurements really fast.
As an initial input list, for reasons of “rough” comparison, we used a list provided by Fernando Gont during an internal workshop he gave at ERNW earlier this year. This initial list included 1425 hosts in total.
We decided to perform our tests using TCP SYN packets to port 80, since we believe that this is the port where most hosts in the real world listen to. First, we wanted to confirm that we could reach our final targets, without using any kind of IPv6 Extension Headers for whatever reason. By doing so, we received:
- 1113 SYN-ACK messages.
- 36 RESET-ACK messages.
- 59 ‘ ICMPv6 ‘, ‘Destination unreachable’, ‘Address unreachable’ messages.
- 43 ‘ICMPv6 ‘, ‘Destination unreachable’, ‘No route to destination’ messages.
- 8 ‘ ICMPv6 ‘, ‘Destination unreachable’, ‘Communication with destination administratively prohibited’, messages.
- 5 of those were sent by the devices themselves, while the rest were sent by another, probably by a firewall.
- 7 ‘ ICMPv6 ‘, ‘Time exceeded’, ‘hop limit exceeded in transit’ messages.
- 2 ‘ ICMPv6 ‘, ‘Destination unreachable’, ‘Reject Route to Destination’ messages.
So, 1268 responses in total. The rest were silently dropped, obviously.
From the above responses we decided to use for our testing purposes only the ones where the final target responded, either with SYN-ACK (1113 hosts) or with a RESET-ACK (36 hosts), 1149 hosts in total.
Then, we sent traffic only to these 1149 “targets”:
A. By using Atomic fragments and
B. By fragmented our IPv6 datagram in two simple fragments.
We got:
A. When Atomic Fragments are used:
954 SYN-ACK (out of the initial 1113, acceptance percentage 85.7%. Not that bad).
35 RESET-ACK responses from the final targets
In summary, (954+35)/(1113+36) = 86.07% in total acceptance rate!
B. Simple Fragmentation
When the TCP SYN packet is fragmented in two simple fragments (but we made sure that the first carries the whole TCP header and the second just the payload to avoid any rejection due to moving part of the layer-4 header at the second fragment).
674 SYN-ACK responses were received (acceptance percentage: 60.55%).
31 RESET-ACK from the final targets (2 RESET-ACKs were sent by intermediate devices, the reset were silently dropped).
In summary, (674+31)/(1113+36) = 61.36% in total acceptance rate!
The corresponding drop rate (38.64%) seems to be even higher than the one described by Fernando (28-30% for web servers) at the “IPv6 Extension Headers in the Real World” draft RFC.
Note: For the time being, we deliberately did not distinguish cases where an intermediate node rejected the traffic towards two or more end-nodes, because our goal was to check how many of them were (not) reachable, for whatever reason. Of course, this means that our sample should be chosen very carefuly in order to be representative.
To sum up:
So, it seems that the acceptance rate of Atomic Fragments (86%) is not that bad (but still, far away from the 100% that we should have in an ideal IPv6 situation), while this rate significantly deteriorates when real IPv6 Fragmentation is used.
I am not blaming administrators, operators, etc. for dropping IPv6 Extension Headers in their environment. From a security perspective, I would definitely do the same: You do not need something, you do not use it. This is why we close all the ports not used in our servers, right? I would take that risk, only if there was a need to use them, for whatever reason. However, the same argument is used by the ones who still refuse to deploy IPv6 in general, right?
However, does this mean that all these IPv6 “functionalities” (aka Extension Headers) should be deprecated? I don’t know. I believe not. No one can be sure that some of them may be needed tomorrow, right? So, for me, the right approach is exactly what happens right now. Leave them as they are (I am not talking about Atomic Fragments but about Extension Headers, generally speaking), drop them now since/if you do no need them, re-enable them later very carefully if/when some of them are needed. Because, I suppose that IPv6 was designed to be the next layer-3 protocols for many-many years, right? Unless, of course, you are a 100% that they are completely uselless, both for now and for the future.
In the meantime, vendors (of networking devices, security devices, operating systems, etc), with all my respect, please do some proper, in depth, testing to your products. We have seen a lot! Not the best approach to come after a vulnerability has been published in order to fix it. You should rather act proactively.
Disclaimer: By no means we consider this to be a fully scientific approach, since the sample that we used was not that big. We believe that the tests must be repeated by using much more samples in order to calculate the acceptance ratios per case, as well as the corresponding confidence intervals.
Write a comment