Open Shortest Path First (OSPF) protocol implementations may improperly determine Link State Advertisement (LSA) recency. According to RFC 2328 section 13.1, for two instances of the same LSA, recency is determined by first comparing sequence numbers, then checksums, and finally MaxAge. In a case where the sequence numbers are the same, the LSA with the larger checksum is considered more recent, and will not be flushed from the Link State Database (LSDB). Since the RFC does not explicitly state that the values of links carried by a LSA must be the same, it is possible with vulnerable OSPF implementations for an attacker to craft a LSA with invalid links that will result in a larger checksum and thus a 'newer' LSA that will not be flushed from the LSDB. Propagation of the crafted LSA can result in the erasure or alteration of the routing tables of routers within the routing domain, creating a denial of service condition or the re-routing of traffic on the network. Attackers with the ability to transmit messages from a routing domain router may send specially crafted OSPF messages to erase or alter the routing tables of routers within the domain, resulting in denial of service or the re-routing of traffic on the network.
Acknowledgments: Name: CERT Upstream: Adi Sosnovich, Orna Grumberg, Gabi Nakibly
CERT advisory: http://www.kb.cert.org/vuls/id/793496
Created quagga tracking bugs for this issue: Affects: fedora-all [bug 1476075]
Statement: For an attacker to exploit this vulnerability, they would either need to control an OSPF peer or spoof a message into the routing domain that appears to come from an OSPF peer. The OSPF trust model is not considered robust against malicious or compromised peers influencing the routing table. Message spoofing is effectively prevented by requiring authentication. Red Hat Product Security has rated this issue as having Moderate security impact. This issue is not currently planned to be addressed in future updates. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.
External References: https://www.kb.cert.org/vuls/id/793496 https://www.quagga.net/docs/quagga.html#ip-ospf-authentication-message_002ddigest
Mitigation: It is strongly recommended to configure Quagga to require authentication from OSPF peers (eg `ip ospf authentication message-digest `). Message digest authentication effectively prevents even a man-in-the-middle attacker from exploiting this vulnerability or otherwise interfering with the routing table, as any message without a proper cryptographic signature will be rejected.