Does Wireshark pose a threat when installed on a server in the DMZ?

A proper DMZ will isolate hosts on the DMZ from each-other in addition to managing access between the hosts and the internet / internal network. The DMZ environment provides for a single choke-point to enforce security and access policies, and provides one single point to monitor traffic into, out of, and within the DMZ.

A DMZ isn't just a network that has access to the internet and the internal network. That's called a security risk and poor planning.

There are potential buffer overruns and security risks with any application that is taking data from uncontrolled sources, especially if the application is running with root / superuser privileges. This is true of wireshark, this is true of sendmail, IIS, true of anything.

To my knowledge, there aren't any "RDP back doors" in wireshark.

My point is "So what if it does open a back-door?"

A proper DMZ should

1. prevent that compromised system from interacting with anything else except in the predefined manner (DNS to the DNS server, ftp to the FTP server, http to the http server, but no ssh to anything, no rdp from anything to anything, etc)
2. Identify that improper traffic is attempting to take place (I just got an alert that the SQL server is getting RDP / VNC traffic from the FTP server!)
3. Be easy to use for everyone else in the enterprise. If the DMZ properly enforces security, it is safer to put "dangerous" things there than in the enterprise network. Would the DMZ team rather have a back-door into the enterprise network or into the DMZ? The answer should be "DMZ, because we monitor and restrict traffic into and out of the DMZ."

I'm not completely in agreement with the DMZ descriptions described above. The security professionals who operate the DMZ probably have "paranoid" in their job descriptions and the DMZ is a "production" space, so see it from their point.

Many of the vulnerabilities cited occur due to flaws in packet dissectors, which are only used during the interactive rendering of traces. This interactive access does not require the same elevated privileges required for packet capture.

Since what you seem to need this for is analyzing local packet capture from the web server, why not separate the functions? Run packet capture on one host, and do the analysis (keeping the dissectors up to date, etc) from another, more restricted, non-production segment after retrieving the trace files.

See

Wireshark Security: http://wiki.wireshark.org/Security

Platform-Specific information about capture privileges: http://wiki.wireshark.org/CaptureSetup/CapturePrivileges

and implement the practices described there.

Wireshark doesn't offer any networking service and doesn't open any port on the system it's running on, so this just doesn't make sense. Having it installed on a system doesn't pose any security threat on its own.

The only potential risk here is, if someone manages to take control of that server, he can use Wireshark to examine network traffic in the DMZ. But, if someone takes full control of your server, he could also install any program he wants on it... so not having it installed wouldn't stop him from installing it, if he wants to.

I really can't see any problem in installing it on a server.

Wireshark has suffered from its fair share of remote compromise vulnerabilities [CVE-2010-1455, CVE-2010-0304, CVE-2009-4377 + 8, CVE-2009-4376] (CVE lists hundreds). As anyone whose gone to Defcon or the Blackhat security conventions knows, Running any sort of packet sniffing software is wildly dangerous if you're in a secure environment. I'd guess that practically every Security Metrics book published in the last few years would strongly recommend against it.

That said, a proper DMZ would prevent an attacker from gaining any leverage anyway, however, you need to weigh the potential of your IDS or routing control software of choice to be compromised with the usefulness of running WS.