CVE-2024-24479 - Buffer Overflow in Wireshark Explained

CVE-2024-24479 is a reported security issue involving a buffer overflow vulnerability in Wireshark, one of the world’s most popular network analysis tools. The bug supposedly affected Wireshark versions before 4.2., specifically in wsutil/to_str.c and the way the software handles formatting of fractional nanoseconds (format_fractional_part_nsecs). The implication was that a remote attacker could send malicious network packets, causing Wireshark to crash — a textbook denial of service (DoS).

However, there’s a twist: Wireshark’s own developers have publicly disagreed with this claim, stating that no released version was ever affected by this issue.

This exclusive post breaks down the vulnerability report, code details, how such an attack could (in theory) work, and links to original references. We’ll also discuss why Wireshark’s vendor disagrees with the CVE’s assessment.

What is a Buffer Overflow?

A buffer overflow is a security flaw that happens when a program writes more data to a block of memory (a buffer) than it was designed to hold. In serious cases, this can let an attacker execute code, crash the app, or get unauthorized access.

The CVE entry reported that the vulnerable code was found in

- File: wsutil/to_str.c

Functionality: handling the function called format_fractional_part_nsecs

This part of Wireshark is responsible for formatting how fractional nanoseconds are displayed, which often appears in timestamp precision.

If a malformed packet or capture file could trigger the overflow — that is, it provides a timestamp that leads to writing too much to a buffer — Wireshark could potentially crash.

Example Code Snippet (Simplified)

Below is a simplified example (not actual Wireshark code!) to illustrate how this type of bug could happen:

/* Hypothetical vulnerable function */
void format_fractional_part_nsecs(char *dest, const char *src) {
    char buf[16];
    /* Imagine src is bigger than 16, leading to overflow */
    strcpy(buf, src); // UNSAFE: no length check!
    sprintf(dest, "%s", buf);
}

An attacker could craft a string longer than 16 bytes, causing buf to overflow and potentially crash Wireshark.

However, the real code in Wireshark is much more complicated, and the developers believe that such a vulnerability does not exist in any distributed version (see below).

How Would an Attack Work?

1. Malicious Network Traffic: An attacker creates and sends malformed packets or prepares a crafted .pcap (packet capture) file with very large or weird timestamps.

User Loads File in Wireshark: The user opens the file or inspects the traffic with Wireshark.

3. Application Crashes: Due to improper handling of the timestamp data, the buffer overflows, causing Wireshark to crash (leading to denial of service).

Note: There is NO evidence of actual exploitation in the wild, and the specifics of the overflow could not be practically shown with any public proof-of-concept code for Wireshark versions.

Vendor Dispute: Was Wireshark Ever Vulnerable?

Wireshark’s maintainers have been clear: they dispute CVE-2024-24479’s impact.

Their statement

> “Neither release 4.2. nor any other release was affected. We disagree with the CVE description.”

The developers reviewed the code, fixed a (potential but not released) issue during version control, but this code never shipped. Therefore, they argue no real-world exploit is possible against the distributed binaries.

References

- CVE-2024-24479 on MITRE
- Wireshark Security Advisories
- Original Wait for Vendor Dispute — Gitlab Issues
- WSUTIL Source Directory

Conclusion

While CVE-2024-24479 was reported as a buffer overflow in Wireshark’s handling of fractional nanoseconds, the Wireshark development team flatly denied that any released version was ever vulnerable. As a result, no practical exploit or real-world risk currently exists, yet it’s a good reminder to keep your network tools updated, watch vendor advisories carefully, and treat disputed vulnerabilities with a healthy mix of skepticism and vigilance.

Timeline

Published on: 02/21/2024 19:15:09 UTC
Last modified on: 08/29/2024 20:36:14 UTC