CVE-2024-24476 - Buffer Overflow in Wireshark (pan/addr_resolv.c, ws_manuf_lookup_str()) – Disputed by Vendor

Wireshark is one of the most widely used network protocol analyzers. In early 2024, the cybersecurity community posted an alert about a possible serious flaw: CVE-2024-24476. This vulnerability allegedly allowed remote attackers to crash Wireshark using a buffer overflow in the code handling Bluetooth PAN (Personal Area Network) addresses. But, as we’ll see, the story isn’t so simple—Wireshark’s developers dispute the issue even exists.

This long read will clarify the details, show the disputed code path (and a PoC), and explain what’s really going on.

Vulnerability: Buffer overflow

- Impacted File: pan/addr_resolv.c

Wireshark Versions: Before 4.2. (according to some reports)

- CVE: CVE-2024-24476

Short Summary

The warning was that certain size checks around the manufacturer name lookup for Bluetooth PAN addresses were insufficient. This could cause a buffer overflow and crash Wireshark.

Here’s the part of code under suspicion, simplified for clarity

// pan/addr_resolv.c

char *ws_manuf_lookup_str(const guint8 *addr, size_t size) {
    char buf[64];
    // ... do some processing ...
    if (size > 64) {
        // Maybe a missing check here?
        // (This is old code, just for demo.)
        memcpy(buf, addr, size);   // Potential overflow if 'size' is too big!
    }
    // Return the string
    return g_strdup(buf);
}

If size is past 64, memcpy would write outside buf’s memory, which in C is a classic buffer overflow. In theory, an attacker could send a special packet with an enormous PAN address to Wireshark, and cause a crash or even possibly run code.

Let’s say a malicious packet is constructed with a big 80-byte “Bluetooth address”

# Minimal PoC creating capture file with oversize PAN addr
import scapy.all as scapy

# Filling an 'address' with 80 bytes instead of normal 6
overflow_addr = b"\x41" * 80
pkt = scapy.Raw(load=overflow_addr)

# Write to pcap, then load in Wireshark
scapy.wrpcap("pan_overflow.pcap", [pkt])

If Wireshark were vulnerable, opening this file could crash it.

Mitigation

According to release notes, Wireshark 4.2. and later are NOT vulnerable.
Even more: the Wireshark development team officially disputed the existence of the flaw. Their review found that neither the reported release nor any other official release had exploitable code here. The function in question doesn’t allow out-of-bounds sizes, or is not called in a way that untrusted data could trigger an unsafe path.

If in doubt:

References and Further Reading

- CVE-2024-24476 on MITRE
- Wireshark bug tracker issue #19155 (vendor dispute)
- Wireshark 4.2. Release Notes
- Common buffer overflow attacks in C

Vendors need to verify if actual releases are at risk and sometimes dispute CVEs.

In this case:
> “Neither release 4.2. nor any other release was ever actually affected.”
> — Wireshark Development Team

Takeaway

CVE-2024-24476 is a classic “better safe than sorry” report—someone noticed an unsafe code pattern, it got a CVE, but was later disputed and is not exploitable in any shipped Wireshark release. That’s reassuring for Wireshark users, but it’s a reminder to keep software updated and monitor CVE advisories closely.

PRO TIP: Always check the vendor’s own security pages for disputes, denials, or clarifications about any vulnerability you hear about online.


If you want more deep dives and exclusive takes on new CVEs, follow my page for updates and code insights.

Timeline

Published on: 02/21/2024 19:15:09 UTC
Last modified on: 08/22/2024 18:35:04 UTC