Dear readers,
As you may have already noticed, Cisco released an urgent security advisory describing an IPv6 Neighbor Discovery DoS Vulnerability in several flavors of Cisco’s operating systems. Currently IOS-XR, XE and NX-OS are affected while ASA and “classic” IOS are under investigation. At first glance, it might look like yet another IPv6 DoS vulnerability. Looking closer, Cisco is mentioning an unauthenticated, remote attacker due to insufficient processing logic for crafted IPv6 NDP packets that are sent to an affected device. Following the public discussion about the vulnerability, it seems that these packets will reach the, probably low rate-limited, LPTS filter/queue on IOS XR devices “crowding” out legitimate NDP packets resulting in a DoS for IPv6 traffic, or in general a high CPU load as these packets will be processed by the CPU. More details are currently not available, but this might indicate the affected systems aren’t doing proper message validation checks on NDP packets (in addition to the LPTS filter/queue problem).
What exactly are the message validation checks? As all Neighbor Discovery Protocol related packets are only relevant for the local link, these checks shall ensure that e.g. packets will not get forwarded by a routing device. RFC 4861 defines these message validation checks for different NDP packets as follows.
Section 6.1.1 (Router Solicitation) defines:
A router MUST silently discard any received Router Solicitation
messages that do not satisfy all of the following validity checks:
- The IP Hop Limit field has a value of 255, i.e.,
the packet could not possibly have been forwarded by a router.
- ICMP Checksum is valid.
- ICMP Code is 0.
- ICMP length (derived from the IP length) is 8 or more octets.
- All included options have a length that is greater than zero.
- If the IP source address is the unspecified address,
there is no source link-layer address option in the message.
Section 6.1.2 (Router Advertisement) defines:
A node MUST silently discard any received Router Advertisement
messages that do not satisfy all of the following validity checks:
- IP Source Address is a link-local address. Routers must use
their link-local address as the source for Router Advertisement
and Redirect messages so that hosts can uniquely identify routers.
- The IP Hop Limit field has a value of 255, i.e.,
the packet could not possibly have been forwarded by a router.
- ICMP Checksum is valid.
- ICMP Code is 0.
- ICMP length (derived from the IP length) is 16 or more octets.
- All included options have a length that is greater than zero.
Section 7.1.1 (Neighbor Solicitations) defines:
A node MUST silently discard any received Neighbor Solicitation
messages that do not satisfy all of the following validity checks:
- The IP Hop Limit field has a value of 255, i.e., the packet
could not possibly have been forwarded by a router.
- ICMP Checksum is valid.
- ICMP Code is 0.
- ICMP length (derived from the IP length) is 24 or more octets.
- Target Address is not a multicast address.
- All included options have a length that is greater than zero.
- If the IP source address is the unspecified address, the IP
destination address is a solicited-node multicast address.
- If the IP source address is the unspecified address, there is no
source link-layer address option in the message.
Section 7.1.2 (Neighbor Advertisements)
A node MUST silently discard any received Neighbor Advertisement
messages that do not satisfy all of the following validity checks:
- The IP Hop Limit field has a value of 255, i.e., the packet
could not possibly have been forwarded by a router.
- ICMP Checksum is valid.
- ICMP Code is 0.
- ICMP length (derived from the IP length) is 24 or more octets.
- Target Address is not a multicast address.
- If the IP Destination Address is a multicast address the
Solicited flag is zero.
- All included options have a length that is greater than zero.
The highlighted requirement is relevant for our discussion here. As you can see, every NDP related packet MUST (RFC 2119) have a Hop Limit value of 255 (to be processed by a recipient). In theory a NDP packet shall never be forwarded by a “node”, but what is a “node” exactly? Looking at RFC 2460 a “node” is a “a device that implements IPv6”. It may be an ambiguity of the specs, but at least in my interpretation (and I maybe wrong here) these checks also apply for routers.
So, do we have a problem? Afterall, the remote scenario shouldn’t be relevant as remote NDP packets should never hit our border router. Well, I got curious and did some “light” testing in regards to forwarding of NDP packets and the result were “unexpected” (to put it mildly). What I did was sending different NDP packets from my home connection to our company gateway (over the Internet) to get a feeling whether the remote scenario might have some relevance.
As a baseline I just did a simple traceroute to see the path the packet is taking towards our gateway:
traceroute to 2003:60:4010::8 (2003:60:4010::8), 30 hops max, 80 byte packets
1 fritz.box (2a02:8071:xxxx:xxxx:2665:11ff:fe02:41b6) 1.417 ms 1.539 ms 1.873 ms
2 2a02:8071:a00::1 (2a02:8071:a00::1) 18.354 ms 18.284 ms 18.181 ms
3 2a02:8071:fd:36c0::1 (2a02:8071:fd:36c0::1) 18.077 ms 17.967 ms 17.589 ms
4 de-kae01a-rd1.kae.unity-media.net (2a02:8071:2000::3) 18.801 ms 20.237 ms 20.167 ms
5 * * *
6 * de-fra01b-ri1-ae14.fra.unity-media.net (2a02:8070:fe:100::2) 21.160 ms 20.932 ms
7 2003:0:1308:c01e::1 (2003:0:1308:c01e::1) 27.690 ms 22.371 ms 22.277 ms
8 * * *
9 2003:0:4702:c402::2 (2003:0:4702:c402::2) 31.007 ms 27.096 ms 27.047 ms
10 2003:60:4010::8 (2003:60:4010::8) 27.004 ms 26.846 ms 26.790 ms
As can be depicted from the output above, my local provider is Unity Media and our gateway is located within the AS of Deutsche Telekom.
To send arbitrary NDP related packets I used Chiron from Antonios Atlasis.
I started with a simple Neighbor Advertisement packet destined to our gateway and used the following chiron command:
root@kali:~/chiron_v0.9/Chiron_0.9/bin# ./chiron_local_link.py eth0 -neighadv -d 2003:60:4010::8
In parallel, I was watching on our gateway whether the packet arrived. I honestly expected that I wouldn’t see anything, but (unfortunately) I was wrong, as the following log entry on our gateway shows:
4866887: May 28 16:19:38.585 CEST: %IPV6_ACL-6-ACCESSLOGDP: list IPv6_IN_INT_G0/0/1
permitted icmpv6 2A02:8071:xxxx:xxxx:DC78:8:842:EF7A -> 2003:60:4010::8 (136/0), 1 packet
As we can see, the Neighbor Advertisement packet arrived on our gateway. Let me repeat, a packet which MUST NOT under any circumstances be forwarded was sent through two provider networks until it eventually arrived on our gateway.
This must just be unfavorable circumstances right? Well, unfortunately not, as even Router Solications (!) and Router Advertisements (!) were forwarded:
4868701: May 28 17:02:42.288 CEST: ICMPv6: Received R-Advert,
Src=2A02:8071:xxxx:xxxx:DC78:8:842:EF7A, Dst=2003:60:4010::8
4868715: May 28 17:02:59.892 CEST: ICMPv6: Received R-Solicit,
Src=2A02:8071:xxxx:xxxx:DC78:8:842:EF7A, Dst=2003:60:4010::8
Again, I was really surprised about the results, as I have thought (maybe naively) that these packets will never be forwarded. Every tested NDP packets was forwarded by all intermediate devices between my home network and our gateway. Each of these devices, which are pretty certainly from different vendors, are just blindly forwarding these packets even though they fail the message validation checks specified in RFC 4861.
Coming back to the advisory, the remote scenario is indeed feasible and an attacker may be able to perform a DoS against your network devices from basically everywhere with crafted IPv6 NDP packets…
So, as there are currently no fixes available what can one actually do to mitigate the vulnerability?
As NDP packets are only relevant on the local link, it is a good idea to restrict the NDP related packets to the link-local scope with the use of ACLs on your border router. Additionally, when e.g. your default route points to a global address of the PE, you have to make sure that NDP packets between the global addresses are also allowed. This translates to the following ACE entries I have deployed on our gateway to mitigate the vulnerability:
permit icmp FE80::/10 any nd-na
permit icmp FE80::/10 any nd-ns
permit icmp host 2003:60:4010::1 host 2003:60:4010::8 nd-na
permit icmp host 2003:60:4010::1 host 2003:60:4010::8 nd-ns
Please be aware that the ACE you have to deploy might (well: must 😉 differ from the ones above. Failing in permitting the correct addresses will break your IPv6 connectivity. Handle with care 😉
One additional note for NX-OS devices. According to the corresponding BugID CSCuz80276 (Login required), there won’t be a fix for the issue as it is a NX-OS platform limitation. It is strongly recommended to apply mitigation techniques to address the vulnerability.
If you happen to have a Cisco based IPS system deployed, the corresponding signature file for this vulnerability can be downloaded here.
Conclusion:
While the vulnerability is pretty ugly, further “research” showed that there might be a bigger problem at hand when intermediate devices blindly forward NDP related packets even though the message validation failed. There needs to be further work done to get a better picture about this issue. In the interim, we recommend to deploy an ACL to restrict NDP to only the relevant/necessary devices until fixed software versions are available.
If you have any questions please leave a comment or contact me on Twitter.
Have a great productive week everybody!
Cheers,
Christopher