Breaking

CVE-2016-1409 – IPv6 NDP DoS Vulnerability in Cisco Software

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

Comments

  1. Thank you for the a great post. I cant entirely agree on the ACL. Here is my version, a bit generalized as I also assume there can be >2 hosts on the link

    ! Any link local sourced ND is ok
    permit icmp fe80::/10 any nd-na
    permit icmp fe80::/10 any nd-ns
    ! Must accept SNMA destination
    permit icmp any ff02:0:0:0:0:1:ff00::/104 nd-ns
    ! Any ND sourced from local subnet is ok but upstream must have RPF
    permit icmp any nd-na
    permit icmp any nd-ns
    ! Observe the log and remove the log keyword when it has worked fine for some time
    deny icmp any any nd-na log
    deny icmp any any nd-ns log

    1. Hi Herman,

      thank you for your comment.

      As I said in the post, one has to modify the ACL for their specific environment.

      I thought about the SNMA, but as the entry for our upstream was already in the neighbor cache the entry isn’t necessary in our case, but it doesn’t hurt to include it in a more general ACL.

      Cheers,
      Christopher

  2. The intermediate routers do not perform the RFC 4816 validation checks because they are not the IPv6 destination of the packet.
    A router checks early on in the packet processing cycle if the destination IP address is one of its own addresses. If not then it will be seeking to simply route the packet, and not to perform validation checks on it.
    Performing validation checks would involve handling the packet in software, whereas most high end routers currently in the internet handle data plane traffic with ASICs, and only punt the minimum traffic to the CPU.

  3. I have proved this in a virtual environment! … I expect this works because the routers along the path do not look perform DPI, and considering, generally, an ICMP packet CAN be sent over the Internet (ECHO and ECHO reply), the router assume it is a ping and doesnt think to check it.

    This lead to me try and send an RA or an NS to a Windows 10/Ubuntu Desktop machine to see if it will accept a NDP packet with a hop count less than 255…. and it does not…. so the next question is can we encapsulate an IP packet containing an IP header in another IP header and there for the outer header is taking the hit, as a result, when it hits the device the hop count is 255 and bang….
    I am trying to do this in SCAPY, however, I am not sure how we can do the IP ‘Tunneling’ or even if that feature exists ?! I have been trying to use ESP extension header with no encryption but so far I cannot get it right, any advice would be appreciated.

Leave a Reply to Christopher Werny Cancel reply

Your email address will not be published. Required fields are marked *