Bugzilla – Bug 1039315
VUL-2: CVE-2017-3224: quagga: Routing table poisoning by invalid links
Last modified: 2024-04-18 07:42:28 UTC
Created attachment 725227 [details] Description and pcap files Report by: Adi Sosnovich, Orna Grumberg and Gabi Nakibly Vulenrability – Advertising MaxAge LSA: In section 14.1 of the RFC, the following is mentioned: 1. An LSA can be flushed from the routing domain by setting its LS age to MaxAge, while leaving its LS sequence number alone, and then reflooding the LSA. 2. LSA instance (having LS sequence number MaxSequenceNumber) must be prematurely aged and flushed from the routing domain before a new instance with sequence number equal to InitialSequenceNumber can be originated. When a self-originated rogue LSA with MaxSequenceNumber and with invalid links is received by a router, the router should prematurely age the rogue LSA. According to section 14.1, this means that an LSA with MaxAge should be advertised. The RFC intends, albeit does not explicitly state, that the MaxAge LSA must carry the same invalid links that were advertised by the rogue LSA. An OSPF implementation might erroneously send the MaxAge LSA with the valid links (as currently installed in the router’s LSDB), as in the case of several routing vendors. Impact: if the MaxAge LSA does not carry the same links as the rogue LSA, then it may be considered older than the rogue LSA, as per section 13.1 in the RFC. Section 13.1 states that for two LSA instances with equal sequence numbers, the one with the larger checksum value is considered newer. If the rogue LSA has a checksum value which is larger than that of the MaxAge LSA (the checksum value depends on the specific values of the links carried by that LSA), then it will be considered newer, and it will not be flushed from the LSDB. If the rogue LSA is not flushed from the LSDB, then the routing tables are poisoned by the invalid links, which may lead to loss of connectivity. If the MaxAge LSA does carry the same links as the rogue LSA, then it will have the same checksum value as of that of the rogue LSA. Thus, the MaxAge LSA will be considered newer due to his age (see Section 13.1). More details in the attached zip file
This is CVE-2017-3224
Public: http://www.kb.cert.org/vuls/id/793496
https://bugzilla.redhat.com/show_bug.cgi?id=1472873 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. 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.
As described in comment 13: - never use OSPF on unsecured [backbone] networks / OSPF domain - configure authentication preventing attacker from exploiting it - fixing it requires changing some core assumptions in the LSA processing and refresh logic -> risky fix to core logic - the quagga project / upstream is dead/unresponsible -> frr. Back to security-team. Please close as WONTFIX same as Red-Hat did.
-> wontfix