Vulnerability Note VU#472363

IPv6 implementations insecurely update Forwarding Information Base

After receiving a neighbor solicitation request from a system that is on-link and is using a spoofed IPv6 address as the source address, a router will create a neighbor cache entry. When this entry is made, some IPv6 implementations will create a Forwarding Information Base (FIB) entry. This FIB entry may cause the router to incorrectly forward traffic to the device that sent original spoofed neighbor solicitation request.

Note that an attacker must have IPv6 connectivity to the same router as their target for this vulnerability to be exploited. Although this vulnerability has only a local attack vector (NDP messages are not forwarded by routers), flat IPv6 networks can include many hosts and may cover large geographical distances as compared to IPv4 networks.

Similar problems to this issue have been discussed in RFC 3756 "IPv6 Neighbor Discovery (ND) Trust Models and Threats."

II. Impact

Block packets with illogical source addresses

Blocking traffic that originates from unlikely or illogical source addresses (such as addresses which are not on-link or logically part of a network assigned to an interface, such as the antispoof keyword in pf) will protect against this vulnerability. This workaround may cause unintended side-effects such as breaking some non-typical configurations. Vendors may also implement this workaround as a fix.

Use application layer encryption

Applications that use secure authentication and encryption such as https, ssh, and ipsec can mitigate this vulnerability by preventing an attacker from intercepting or parsing any data that received. Note that an attacker will probably still be able to blackhole IP addresses resulting in a local denial of service regardless of the authentication or encryption methods used. As noted in RFC 3971, it is non-trivial to use ipsec to protect the integrity of NDP messages.

Design and deploy segmented networks

In a single IPv6 prefix there are certain trust asumptions and if the same IP range is shared all clients will be considered on-link. Segmenting networks will reduce the likelihood of this and similar vulnerabilities from being exploited. Networks can be segmented by assigning unique prefixes to individual router interfaces or by using VLANs.

Systems Affected

http://tools.ietf.org/html/rfc4861
http://tools.ietf.org/html/rfc4861#section-2.1
http://www.ietf.org/rfc/rfc2461.txt
http://www.ietf.org/rfc/rfc3756.txt
http://www.ietf.org/rfc/rfc3177.txt
http://tools.ietf.org/html/rfc3971
http://docs.sun.com/app/docs/doc/817-0573/6mgc65bb6?a=view
http://msdn.microsoft.com/en-us/library/ms900123.aspx
http://en.wikipedia.org/wiki/Forwarding_Information_Base#FIBs_in_Ingress_Filtering_against_Denial_of_Service
http://en.wikipedia.org/wiki/Reverse_path_forwarding
http://www.openbsd.org/faq/pf/filter.html#antispoof

Credit

Thanks to David Miles for reporting this vulnerability. Numerous vendors and others also provided technical information that was used in this report.

This document was written by Ryan Giobbi, Evan Wright, Chad Dougherty, and Art Manion.

Other Information

If you have feedback, comments, or additional information about this vulnerability, please send us email.