search menu icon-carat-right cmu-wordmark
Carnegie Mellon University

Software Engineering Institute

CERT Coordination Center

IPv6 implementations insecurely update Forwarding Information Base

Vulnerability Note VU#472363

Original Release Date: 2008-10-02 | Last Revised: 2009-04-27

Overview

A vulnerability in some implementations of the IPv6 Neighbor Discovery Protocol may allow a nearby attacker to intercept traffic or cause congested links to become overloaded.

Description

IPv6 networks use the Neighbor Discovery Protocol (NDP) to detect and locate routers and other on-link IPv6 nodes. NDP uses ICMPv6 types 133, 134, 135, and 136. Neighbor solicitation (type 135) messages are used by NDP to discover and determine the reachability of nearby IPv6 nodes. Nodes that can send each other NDP messages are considered to be on-link (as per RFC 4861).

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."

Impact

An attacker may be able to intercept private network traffic. Receiving the traffic may cause links to become congested or saturated due to the additional bandwidth. Administrators are encouraged to read RFC 3756 for more information about other possible vulnerabilities and impacts.

Solution

Consider the workarounds below and consult your vendor.

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.

Vendor Information

472363
 
Expand all

View all 103 vendors View less vendors


CVSS Metrics

Group Score Vector
Base 0 AV:--/AC:--/Au:--/C:--/I:--/A:--
Temporal 0 E:Not Defined (ND)/RL:Not Defined (ND)/RC:Not Defined (ND)
Environmental 0 CDP:Not Defined (ND)/TD:Not Defined (ND)/CR:Not Defined (ND)/IR:Not Defined (ND)/AR:Not Defined (ND)

References

Acknowledgements

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

CVE IDs: CVE-2008-4404, CVE-2008-2476
Severity Metric: 2.70
Date Public: 2008-10-02
Date First Published: 2008-10-02
Date Last Updated: 2009-04-27 12:04 UTC
Document Revision: 99

Sponsored by CISA.

Download PGP Key

Read CERT/CC Blog

Learn about Vulnerability Analysis