On 31 March 2008 the Wireshark project released version 1.0, ten years after Ethereal’s first 0.2.0 in July 1998. The jump to 1.0 is the first release declared feature-complete. On the security side something else weighs more: a protocol analyser is also, in practice, an enormous collection of parsers reading input controlled by third parties.

Context

Wireshark began as Ethereal, written by Gerald Combs from 1997 onwards for network troubleshooting. In 2006 the project changed its name: the Ethereal trademark had been registered by Combs’s former employer and stayed with them, so the codebase moved on under the Wireshark name (ethereal-dev mailing list, June 2006 announcement). Licensed under GPL v2.

It works in two stages: it captures and it dissects. It takes packets through libpcap (Linux, macOS, BSD) or WinPcap (Windows) and breaks them down according to the protocol specifications, in a hierarchical view — Ethernet, then IP, then TCP or UDP, then the application protocol. At 1.0 the recognised protocols number around a thousand: from the fundamentals (IP, TCP/UDP, DNS, DHCP, HTTP) to SMB, SMTP/POP/IMAP, SIP and RTP for VoIP, down to industrial protocols and 802.11 wireless.

The problem

Each recognised protocol has a matching dissector: code that takes an arbitrary byte sequence and reconstructs its structure. It is the pattern from which memory vulnerabilities arise. The bytes come from the network or from a capture file: they are untrusted, and the dissector has to assume they may be malformed on purpose.

This is not theory. In the two years before 1.0 the project published a steady run of advisories on individual dissectors. To stay with the CVE cases: a buffer overflow in the PPP dissector (CVE-2007-6112, version 0.99.6), one in the ANSI MAP dissector (CVE-2007-6115, from 0.99.5 to 0.99.6), problems in the SSL dissector and in the iSeries/OS400 trace parser (CVE-2007-6114). The pattern repeats the same way every time: a crafted packet or capture file, a dissector reading past its bounds, denial of service and in some cases code execution.

The cause is structural: the attack surface grows with coverage. The more protocols Wireshark understands, the more parsing code it needs, the more places where a length check can slip. And every dissector sees hostile input by definition: anyone analysing suspicious traffic is deliberately feeding the program bytes produced by an attacker.

Architecture

The structural answer is privilege separation, and it is why Wireshark’s architecture in 2008 deserves more attention than the changelog.

Capturing raw traffic requires elevated privileges: putting an interface in promiscuous mode is something the operating system reserves to root (or to an account with equivalent capabilities). The naive route is to run the whole program as root. It would be the worst choice, because it would mean running the hundreds of thousands of lines of dissector as root too — the very code that reads hostile input and that has historically had the bugs.

Wireshark splits the two roles into distinct processes:

  • dumpcap is a small, isolated program that does one thing: it opens the interface and reads the packets. It is the only component that needs privileges.
  • The graphical interface (wireshark, a GTK+ GUI) and the command-line version (tshark) receive the packets from dumpcap and dissect them with ordinary user privileges.

The point is this: all the dissection code — the large, complicated code that works on hostile bytes — never runs with elevated privileges. An overflow in a dissector stays confined to an unprivileged process. The privileged dumpcap is small enough to check by hand: it captures, full stop, and does not interpret the contents.

Around the core sits a set of command-line tools that share the dissection engine: editcap to filter and trim capture files, mergecap to merge them, capinfos for statistics, text2pcap to rebuild a PCAP from a textual hexdump. They come in handy because with tshark and these helpers you can script analysis without a GUI, on a headless capture machine.

The critical point

Privilege separation does not eliminate dissector bugs: it downgrades them. A buffer overflow in a parser is still a bug, and on a malformed capture file it can still crash the analysis or, in the worst cases, execute code — but in the context of the user who opened the file, not of root.

The risk shifts, it does not disappear, and the operational consequence is sharp: opening a .pcap file of unknown provenance means running parsing code on hostile data. In incident response, where dumps come from compromised systems and may have been tampered with, the sensible rule is to treat the analysis as a potentially dangerous operation — a dedicated machine, an unprivileged user, an up-to-date build. The same logic that applies to opening a suspicious attachment applies to opening a suspicious capture.

Implications

Wireshark is awkward to handle for a second reason, one that also explains its appearance for years in networking-course demos. Passive capture on unencrypted traffic means seeing in the clear everything that is not encrypted. POP3, IMAP and SMTP credentials without TLS, HTTP sessions, cookies: anyone who shares the network segment and knows how to put the interface in promiscuous mode can read them.

Showing this once to a student is worth more than a lecture on the importance of encrypted transport. Being able to observe traffic is one of the concrete historical reasons for moving to encryption everywhere, even where the content looked harmless. Wireshark makes that threat tangible in thirty seconds.

The tool is dual-use by nature. On the technical level the passive capture of the sysadmin debugging their own network is identical to that of someone intercepting a network that is not theirs. Legitimate use is a question of authorisation, not of capability: it needs an explicit mandate over the network being analysed, and if the capture contains personal data the PCAPs must be anonymised before sharing them for support or teaching.

Limits

Wireshark sees only what passes through the interface it captures on. On a modern switched network, without port mirroring and without being on the traffic path, it sees only its own traffic and broadcast — not the whole network as it did on hubs. On encrypted traffic it sees the metadata (addresses, ports, sizes, timings) but not the contents, unless it holds the keys. And dissection is worth as much as the dissector: a proprietary or unsupported protocol stays a raw byte sequence.

The structural fact remains: a tool that understands a thousand protocols contains a thousand parsers, and each parser is the promise to correctly read input that someone has every interest in making incorrect. The privilege separation of 2008 is the acknowledgement of this, written into the architecture.

https://www.wireshark.org/docs/wsug_html_chunked/ChIntroHistory.html https://wiki.wireshark.org/CaptureSetup/CapturePrivileges https://lists.wireshark.org/archives/ethereal-users/200606/msg00131.html https://nvd.nist.gov/vuln/detail/CVE-2007-6112 https://lwn.net/Articles/189356/ https://www.noze.it/en/insights/wireshark-1-0/

Cover image: Diagram of the TCP/IP protocol stack with Application, Transport, Internet and Link layers; a magnifying glass enlarges the… — diagram by Dave Braunschweig, CC BY-SA 3.0 — https://commons.wikimedia.org/wiki/File:Internet_Protocol_Analysis_-_Application_Layer.png