IPv6 vulnerable to fragmentation attacks that threaten core internet routers
Net boffins float RFC to fix the protocol before things turn nasty
A trio of 'net experts argues that a key IPv6 protocol needs fixing to get rid of a fragmentation attack vector against routers in large-scale core networks.
The vector, called “atomic fragments” has long been regarded with suspicion by IPv6 security wonks. Here, for example, is a Black Hat 2012 presentation illustrating the threat.
Now, prolific Internet Engineering Task Force (IETF) contributor Fernando Gont has helped write RFC 8021, that formally places the feature on the “considered harmful” list.
That's more serious than it sounds: "considered harmful” is code for “get rid of this as soon as possible!"
Fixing this bug is therefore important because a vulnerability in a protocol flows on to any product that implements the protocol – and that would mean vendors at the heart of the Internet, like Cisco, Juniper, Ericsson, Huawei et al - have to deal with it.
While systems using recent BSD and Linux kernels are immune, the point of the RFC is to get rid of the atomic fragment risk at the protocol level.
An atomic fragment is designed into the IPv6 fragmentation mechanism. As RFC 6496 explains them: “when a host receives an ICMPv6 'Packet Too Big' message advertising a 'Next-Hop MTU' smaller than 1280 (the minimum IPv6 MTU), it is not required to reduce the assumed Path-MTU, but must simply include a Fragment Header in all subsequent packets sent to that destination. The resulting packets will thus not actually be fragmented into several pieces but will just include a Fragment Header with both the 'Fragment Offset' and the 'M' flag set to 0 (we refer to these packets as 'atomic fragments').”
The problem is these atomic fragments present a denial-of-service (DoS) vector.
From RFC 8021: “If an attacker sends a forged ICMPv6 PTB [packet too big] error message to Host B, reporting an MTU smaller than 1280, this will trigger the generation of IPv6 atomic fragments from that moment on (as required by [RFC2460]). When Host B starts sending IPv6 atomic fragments (in response to the received ICMPv6 PTB error message), these packets will be dropped, since we previously noted that IPv6 packets with extension headers were being dropped between Host B and Host A. Thus, this situation will result in a DoS scenario.”
Co-author of the new RFC, Fernando Gont of SI6 Networks, explained to The Register that his RFC is the result of long debate in the IPv6 security community.
“This attack vector is essentially based on two different pieces of work: the generation of atomic fragments (i.e., how to trigger fragmentation at a target system), and the filtering of IPv6 fragments (i.e., what actually gets the packets dropped, causing a DoS.”
Fragmentation's troubled history
Gont says he's been looking at atomic fragments since presenting an IPv6 hacking course in 2010, when he and an attendee decided to come up with “an IPv6-version of IPv4's idle/dumb scan” attack.
“We verified that it was possible to trigger the generation of atomic fragments with ICMPv6 PTB packets, and that many implementations were not performing any kind of checks on the received ICMPv6 packets” (such as to ensure the received packets corresponded to an outgoing TCP connection).
Gont conducted more research, and in 2013, found that “such dropping was quite widespread” in the public Internet.
The result was, he found, “with a single packet you could DoS communications between two systems for about 10 minutes. For obvious reasons, if successfully exploited against BGP routers, the impact could be severe.”
Furthermore, Gont told The Register, it's not easy to protect systems with packet filters, because of another IPv6 feature, extension headers.
Extension headers make IPv6 more extensible than IPv4, but because they can daisy-chain together: “IPv6 Extension Headers make packet filtering difficult since the filtering device would need to process/follow the list of extension headers headers in order to get to the actual payload (the ICMPv6 packet, in this case)”, Gont told us.
Filtering devices between two systems are, in fact, a condition for the vulnerability to be exploitable. “Some filtering device between the two communicating systems (or one of the two communicating systems themselves) must be configured to drop IPv6 fragments,” Gont told The Register's networking desk.
“Based on research published in RFC7872 (which I co-authored), it's clear that that's the case for many Internet servers. On the other hand, when it comes to BGP routers, it depends on whether one of the two BGP peers implements a filtering policy that drops IPv6 fragments directed to the BGP router.”
Some systems are not vulnerable, he noted.
“A few implementations (e.g. NetBSD and some versions of FreeBSD) were not implementing this feature,” Gont told us.
“Other implementations (e.g. Linux and OpenBSD) were quick in responding to this issue, and patched their stacks before RFC8021 was published.
“However, some popular server and router implementations still implement this functionality, and hence this attack vector is still exploitable … besides, some deployed systems run older versions of the patched systems, so e.g., you might be able to exploit this attack against a Linux server that is not using the patched kernel.”