Vulnerability Note VU#793496

Open Shortest Path First (OSPF) protocol implementations may improperly determine LSA recency

Original Release date: 27 Jul 2017 | Last revised: 18 Oct 2017

Overview

Open Shortest Path First (OSPF) protocol implementations may improperly determine Link State Advertisement (LSA) recency for LSAs with MaxSequenceNumber. Attackers with the ability to transmit messages from a routing domain router may send specially crafted OSPF messages to poison routing tables within the domain.

Description

CWE-354: Improper Validation of Integrity Check Value

Open Shortest Path First (OSPF) protocol implementations may improperly determine Link State Advertisement (LSA) recency with MaxSequenceNumber. 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 when prematurely aging a self-originating LSA with MaxSequenceNumber, it is possible in vulnerable OSPF implementations for an attacker to craft a LSA with MaxSequenceNumber and 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.

Impact

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.

Solution

Install Updates

The OSPF protocol is a popular interior routing protocol that is used by many devices and manufacturers. This vulnerability is implementation-specific, so some vendors may not be affected. The Vendor Information section below contains known affected or non-affected vendors. Please consult your network equipment vendor to confirm how they are affected by this vulnerability.

Vendor Information (Learn More)

As an implementation vulnerability, CVE IDs are assigned for each known affected codebase:

    • CVE-2017-3224 has been reserved for Quagga and downstream implementations (SUSE, openSUSE, and Red Hat packages).
    • CVE-2017-3752 describes this vulnerability in affected Lenovo products.
    • CVE-2017-6770 describes this vulnerability in affected Cisco products.

VendorStatusDate NotifiedDate Updated
CiscoAffected12 May 201708 Aug 2017
LenovoAffected12 May 201717 Jul 2017
openSUSE projectAffected12 May 201725 Jul 2017
QuaggaAffected17 Jul 201726 Jul 2017
Red Hat, Inc.Affected12 May 201725 Jul 2017
SUSE LinuxAffected12 May 201725 Jul 2017
AppleNot Affected12 May 201705 Jun 2017
Arista Networks, Inc.Not Affected12 May 201717 Jul 2017
CoreOSNot Affected12 May 201712 May 2017
D-Link Systems, Inc.Not Affected12 May 201717 Aug 2017
FreeBSD ProjectNot Affected12 May 201718 Jul 2017
HTCNot Affected12 May 201723 May 2017
Huawei TechnologiesNot Affected12 May 201726 Jul 2017
Intel CorporationNot Affected12 May 201717 Jul 2017
Juniper NetworksNot Affected12 May 201717 Jul 2017
If you are a vendor and your product is affected, let us know.View More »

CVSS Metrics (Learn More)

Group Score Vector
Base 5.4 AV:A/AC:M/Au:N/C:P/I:P/A:P
Temporal 4.9 E:POC/RL:ND/RC:C
Environmental 3.6 CDP:ND/TD:M/CR:ND/IR:ND/AR:ND

References

Credit

Thanks to Adi Sosnovich, Orna Grumberg, and Gabi Nakibly for reporting this vulnerability.

This document was written by Joel Land.

Other Information

Feedback

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