LiveActive security incident?Get immediate response
CVE Record

CVE-2017-3224: Open Shortest Path First (OSPF) protocol implementations may improperly determine LSA recency in affected Quagga and downstream implementations (SUSE, openSUSE, and Red Hat packages)

Open Shortest Path First (OSPF) protocol implementations may improperly determine Link State Advertisement (LSA) recency for LSAs 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. CVE-2017-3224 has been reserved for Quagga and downstream implementations (SUSE, openSUSE, and Red Hat packages).

UnknownCVSS not scoredNot KEV-listedUpdated
Glexia's TakeAutomated analysisunknown

Security readout for executives and security teams

Plain-English summary

This flaw affects some OSPF routing implementations. A crafted routing advertisement can be treated as newer than legitimate data, allowing bad routing information to persist. The result could be broken routing, traffic rerouting, or denial of service inside an affected routing domain.

Executive priority

Treat this as a routing infrastructure risk, not a typical endpoint flaw. Prioritize environments where Quagga-based OSPF participates in production routing, because failure could disrupt connectivity or redirect traffic.

Technical view

CVE-2017-3224 involves improper LSA recency handling for MaxSequenceNumber LSAs. In vulnerable Quagga and downstream SUSE, openSUSE, and Red Hat packages, an LSA with invalid links and a larger checksum may remain in the LSDB instead of being flushed.

Likely exposure

Exposure is most relevant where OSPF is implemented using vulnerable Quagga or downstream SUSE, openSUSE, or Red Hat packages. The provided sources do not identify exact affected package versions, patch levels, or appliance products.

Exploitation context

The source bundle does not report active exploitation, and KEV status is false. Exploitation would require the crafted LSA to propagate within the affected OSPF routing domain, potentially altering or erasing routing tables.

Researcher notes

The core issue is RFC 2328 LSA recency comparison when sequence numbers match and checksum determines freshness. Evidence is limited to the CVE description and CERT reference; exact vulnerable versions and fixes require vendor advisory confirmation.

Mitigation direction

  • Check CERT VU#793496 and vendor advisories for fixed package guidance.
  • Inventory Quagga, SUSE, openSUSE, and Red Hat OSPF deployments.
  • Prioritize updates only against vendor-confirmed affected versions and fixes.
  • Review OSPF routing-domain controls before making operational changes.

Validation and detection

  • Identify systems running Quagga or downstream OSPF packages.
  • Compare installed package versions against vendor advisories when available.
  • Review routing incident history for unexplained OSPF instability.
  • Confirm LSDB and routing-table behavior after any vendor-approved remediation.
Prepared
Confidence
medium
Sources
3

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Potential ATT&CK relevance

Conservative CVE-to-ATT&CK context

These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.

ATT&CK lookup starting points

Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.

cwe · low confidence lookup

CWE-354: Exact CWE lookup

Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.

Open ATT&CK lookup
description · low confidence lookup

Database behavior lookup

The CVE wording references database injection or access, so collection and exfiltration review may help. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.

Open ATT&CK lookup
cve · low confidence lookup

CVE-2017-3224 mapping review

Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Unknown
CVSS
Not scored
Known Exploited
No
Published
Official CVE source material

CNA and ADP enrichment extracted from CVE v5

These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.

0CVSS vectors
0Timeline events
0ADP providers
2Source links

CVSS and timeline data

No CVSS vectors or timeline events were available in the normalized CVE source material.

Source materials

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
Open Shortest Path First (OSPF)ProtocolN/AListed
Weakness

CWE details

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.

CWE-354 · source CWE mapping

Improper Validation of Integrity Check Value

Improper Validation of Integrity Check Value represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.