CVE-2024-20321: Cisco NX-OS eBGP DoS Vulnerability

CVE-2024-20321 Overview

A vulnerability in the External Border Gateway Protocol (eBGP) implementation of Cisco NX-OS Software could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device. This vulnerability exists because eBGP traffic is mapped to a shared hardware rate-limiter queue, enabling an attacker to disrupt legitimate eBGP neighbor sessions by flooding the device with crafted network traffic.

Critical Impact

Successful exploitation allows remote attackers to drop eBGP neighbor sessions, causing network-wide routing disruptions and potential service outages across interconnected autonomous systems.

Affected Products

• Cisco NX-OS versions 7.0(3)F1(1) through 7.0(3)F3(5)
• Cisco NX-OS versions 9.2(1) through 9.3(12)
• Cisco NX-OS versions 10.1(1) through 10.4(1)

Discovery Timeline

• February 29, 2024 - CVE-2024-20321 published to NVD
• November 21, 2024 - Last updated in NVD database

Technical Details for CVE-2024-20321

Vulnerability Analysis

This vulnerability represents a resource exhaustion flaw (CWE-400, CWE-770) in the eBGP implementation of Cisco NX-OS Software. The fundamental issue stems from an architectural design decision where eBGP traffic shares a hardware rate-limiter queue with other traffic types. Under normal operating conditions, this shared queue handles traffic appropriately. However, when an attacker sends large volumes of network traffic with specific characteristics through an affected device, the shared rate-limiter queue becomes overwhelmed.

The attack can be executed remotely over the network without requiring authentication or user interaction. When the rate-limiter queue is exhausted, legitimate eBGP control plane traffic gets dropped alongside the attack traffic. This causes eBGP neighbor sessions to timeout and drop, resulting in routing table instability and potential network-wide outages. The scope of impact extends beyond the vulnerable device itself, as routing changes propagate to peer networks.

Root Cause

The root cause of CVE-2024-20321 is improper resource allocation in the control plane traffic handling mechanism. Specifically, eBGP traffic is mapped to a shared hardware rate-limiter queue rather than having a dedicated queue with guaranteed bandwidth allocation. This design flaw allows high-volume traffic to compete with and ultimately starve eBGP keepalive and update messages, violating the principle of proper resource isolation between different traffic classes.

The vulnerability is classified under CWE-400 (Uncontrolled Resource Consumption) and CWE-770 (Allocation of Resources Without Limits or Throttling), reflecting the failure to adequately protect critical control plane resources from exhaustion.

Attack Vector

The attack vector is network-based and requires the attacker to send large amounts of traffic with certain characteristics through a vulnerable Cisco NX-OS device. The attack does not require authentication, privileged access, or user interaction, making it highly exploitable from any position where an attacker can route traffic through the target device.

An attacker positioned on the network can craft and send high-volume traffic flows designed to consume the shared rate-limiter queue resources. As eBGP relies on timely keepalive exchanges to maintain neighbor relationships, the inability to process these messages results in session timeouts and subsequent routing disruptions.

Detection Methods for CVE-2024-20321

Indicators of Compromise

• Unexpected eBGP neighbor session flaps or state transitions to Idle/Active without configuration changes
• High CPU utilization on control plane processors during traffic surges
• Syslog messages indicating BGP holdtime expiration or neighbor session resets
• Abnormal increases in dropped packets on rate-limiter queues

Detection Strategies

• Monitor eBGP session state changes using SNMP traps or syslog alerts for %BGP-5-ADJCHANGE messages
• Implement baseline analysis for normal eBGP traffic patterns and alert on significant deviations
• Use NetFlow or sFlow to detect unusually high traffic volumes traversing BGP-enabled interfaces
• Configure rate-limiter queue monitoring to track queue depth and drop rates

Monitoring Recommendations

• Enable BGP session monitoring dashboards in network management systems with alerting thresholds
• Configure real-time syslog forwarding to a SIEM platform for correlation of eBGP session events across the infrastructure
• Implement periodic checks of show system internal access-list tcam region and related commands to monitor control plane resource utilization
• Establish automated alerting when multiple eBGP sessions drop simultaneously, indicating potential exploitation

How to Mitigate CVE-2024-20321

Immediate Actions Required

• Review the Cisco Security Advisory for affected version details and fixed releases
• Inventory all Cisco NX-OS devices running versions 7.0(3)F, 9.2.x, 9.3.x, 10.1.x, 10.2.x, 10.3.x, or 10.4(1)
• Prioritize patching of devices at network perimeters or those handling high volumes of inter-AS traffic
• Implement network access controls to limit traffic sources that can reach vulnerable eBGP interfaces

Patch Information

Cisco has released software updates that address this vulnerability. Organizations should upgrade to a fixed release of Cisco NX-OS Software as specified in the Cisco Security Advisory. Consult the advisory for the specific fixed release versions corresponding to each affected train. Testing in a lab environment is recommended before production deployment to verify compatibility with existing network configurations.

Workarounds

• Implement Control Plane Policing (CoPP) to rate-limit traffic destined to the switch CPU, providing additional protection for BGP traffic
• Configure hardware-based access control lists (ACLs) to restrict BGP traffic sources to known, trusted peer addresses
• Enable BGP TTL Security (GTSM) to reject BGP packets with TTL values below configured thresholds, limiting attack surface to directly connected peers
• Consider deploying BGP traffic to separate VRFs with dedicated rate-limiter resources where supported

# Example CoPP policy configuration for BGP protection
copp profile strict
class copp-system-p-class-critical
  priority level 1
  police cir 19000 kbps bc 250 ms conform transmit violate drop