Every once in a while there is some news about Wireshark being vulnerable to being attacked/exploited/pwned, meaning that there is a way to craft frames/packets in a pcap/pcapng file to make Wireshark crash and (if done right) execute malicious code. So let’s take a look at what that means and what can be done about it.

I am using Wireshark almost every day (yes, Weekends, too), and have been for the last 15 years. Well, technically it was still Ethereal back then, and I sometimes ran it in form of the now long forgotten Packetyzer because it looked nicer on Windows. It’s an awesome tool to find out what is happening in those packets, even though it is not always 100% correct on what it shows. But that’s something you have to live with, because it’s a really complex task to dissect and diagnose all those protocols. And I don’t know any protocol analyzer that’s doing it any better than Wireshark does. Many are worse.

Crashing Wireshark on purpose

Now, when it comes to crashing Wireshark on purpose I have done that a few times, mostly to find the reason for it and open a bug report. The process itself is simple but can take some time – I usually use editcap to split the crashing pcap file into smaller files, either by specifying the number of packets per file I want with the “-c” parameter, or by start and stop time stamps via “-A” and “-B” parameters. Repeat until you have the smallest file possible to reproduce the crash (which often enough is just a single packet). One time, my friend and coworker Oliver asked me not to open a bug report right away when I found out that a specific packet could crash the “color coding” code. The reason was that he wanted to check if he could exploit it first. It turned out the crash wasn’t good enough for that, but in the end, this is how you’d attack Wireshark. Feed it something that makes it misbehave, and misbehave in a way that allows you to execute your code afterwards.

The main problem with Wireshark as an attack surface is that it is a monster of an application when it comes to lines of code and functionality. The following slide from the 2018 Sharkfest US Wireshark conference presented by Gerald gives you some idea how complex it is:

Figure 1 – Sharkfest 2018 US Keynote (click here to watch)

The important lines here are: 1400+ authors, 2400 protocols, with a total of at least 2.5 million lines of code, depending on how you count them. As someone said on Twitter, the first open source project that comes to mind in a similar (well, bigger) way is the Linux kernel development.

The attack surface

As we all probably know not every person writing code will do it as meticulously in regard to security aspects as someone like Dan J. Bernstein. Most developers need to get things done, so code is written in a hurry, and many of them do not even care about security. “Why would anyone attack my packet dissector? I just wrote it for some quick peak into what our protocol is doing, so no, I didn’t spend to much time on making it safe. It’s fine as long as it works with our pcaps” is probably something you’d hear a lot if you ask all 1400+ authors. Plus the ones you don’t even know about, because there are a lot of companies doing in-house dissector development for their proprietary protocols and never publish the code for it. Which doesn’t mean it can’t be attacked and used as an attack vector, but of course that is less likely than doing that to one of the dissectors where the code is public.

Fun fact: there is at least one block of dissector code for a proprietary vendor protocol that made it into the public Wireshark code base by mistake. I found one of them when I asked if I could get the protocol specs to implement it into TraceWrangler, and was told that “uh, no, sorry – it shouldn’t even be in the public Wireshark builds in the first place…” 😀

The main problem with Wireshark and it’s attack surface is that it’s pretty big. You can’t fix all the bugs in all the dissectors, because nobody has the time to do that. And then there’s dissector code that nobody maintains anymore. Even finding them in the first place isn’t always that easy. The Wireshark core developers do their best to fix whatever they can, and they keep fuzzing the code day and night with tons of valid and broken pcap files. But that still doesn’t find all the problems. A security researcher (with good or bad intentions) who wants to find a way to attack that code base will always be able to with enough dedication and time on their hands.

Assessing the risk

Alright, so we can agree on Wireshark offering a large attack surface. So let’s see what we can do about that. When it comes to risk assessments, we have two main aspects to look at:

1. Probability – what is the probability that an attack vector is going to be used against the target
2. Impact – how bad will it hurt if the attack actually happens

This may be a simplified view on risk assessment, but for this post I’ll try not to complicate things. If you’re interested, another and more complex approach can be found here.

Bluntly speaking, we need to find out how likely it is to be opening a “bad” pcap file in Wireshark, and what’s the worst thing that could happen if it succeeds in crashing it with the attacker’s code being executed in a perfect way. Just in case you’ve never written exploit code before: no, it doesn’t always work perfectly. In fact, most exploits fail in a very high percentage of cases. The really good ones are those that work almost every single time they’re executed, and they’re pretty rare (e.g. Eternal Blue comes to mind as a pretty successful example). Talking about worst case scenarios – if you haven’t read it, read the excellent story about NotPetya to get a sense of “oh my god, this is a mess!”, where a single server running a small (probably deemed irrelevant) accounting application allegedly caused a total failure of the company’s worldwide corporate IT landscape.

So, what’s the probability that you’re going to open a “bad” pcap file in Wireshark? Well, that hugely depends on what you’re working on:

• if you’re troubleshooting TCP for e.g. your own application, or a well known one, chances are slim to none that there’s suddenly some bad packet in the pcap, assuming you filtered on just the traffic you needed during capture
• if you’re doing bulk capture (“grab everything, sort it out later”) on your internal network you are a little more prone to catch the bad stuff. But for that it needs to be on the network you’re capturing already, so the risk is pretty low again. Why? Because if an attacker already has access to your network to inject that kind of stuff, he’s probably going do to easier things instead than hoping that anyone will “catch the flu” by chance. Attackers are lazy, like everybody else, so few go the extra mile to do something like that, and then Wireshark being exploitable is the least of your problems. In my experience, few people are capturing packets in the networks at all unless there’s a problem they need to fix (reactive, instead of proactive). And if they do, their proactive capture solutions often are commercial appliances, not Wireshark. They may be running tshark in the background, though 🙂
• The good, the bad, the ugly: if you perform a capture at an internet uplink, or some other network link where you simply don’t know what kind of traffic will arrive you should be a lot more careful. The problem is that you don’t have control over the sources of the packets, so there may be someone sneaking in some bad ones. And a single bad packet may be enough to successfully attack Wireshark and do some bad stuff to your computer or network.
• Malware analysis – this is probably one of two with the highest risk, because some malware author may add malicious packets to his Command & Control communication to mess with Wireshark, either to delay your reverse engineering processes, or to even pwn you. In that case you should be really careful.
• Forensic investigation of an ongoing attack (you know, those which people call “APT”, as if  most of weren’t using really simple attack vectors in almost all cases) – if you’re investigating a network breach where you’re unsure if the attackers are still able to access your network you should assume they can inject malicious packets into your capture. In those cases I do analysis on a workstation that doesn’t have any kind of network connectivity to analyze the packets, and re-image it afterwards. I draw the line for that kind of setup at caring about air-gap defeating stuff like inaudible sound, hard disk noise, keyboard sniffing (I’m not using wireless keyboards, anyway), and all the other fancy lab level “I can still communicate over air gaps” stuff.

Now, for the worst thing that could happen – I think it’s safe to say that if you run Wireshark with admin privileges on a Domain Controller to open a pcap file with questionable origin you’re pretty much doing everything you can do, in the most irresponsible way possible. So don’t do that. Other than that the minimum impact of a successful Wireshark attack is that the attacker can do something bad on your PC, e.g encrypt some local files etc. Unless the attacker also has a privilege escalation trick up his sleeve, of course.

Scenarios & Countermeasures

I learned the hard way that warning a large corporate customer about attack vectors against Wireshark can lead to problematic results when they react by banning the use of Wireshark completely because of it. Think of a SOC analyst environment where Wireshark is not allowed at all for use in an investigation. Yeah, that makes their life a lot harder. Thankfully, that situation has been resolved in the meantime, but it was a problem for a little while.

So, let’s take a look at the top four course of actions you can take to mitigate (or, more accurately: reduce) the risk of having your Wireshark being pwned:

#4 – Isolate your analysis environment

If you’re working on pcap file that have a high probability of containing malicious stuff (malware samples, C&C traffic, broken protocols) you might want to run Wireshark on a physical Workstation in a controlled network environment that cannot escape into the wild. Or one with no networking at all. It’s often painful to work on packets that way because you can’t do Internet lookup tasks like you’re used to, but then again it’s the old principle of security being the enemy of convenience. In most cases where I have worked that way there are two or more workstations next to each other, one air-gapped (or at least on an isolated malware lab network), and at least one with internet access that I could use to do research. For forensic investigations, re-image your analysis workstations after each case.

#3 – run Wireshark in a VM

This one is a little more convenient version of #4, because you’re running both the isolated and the normal environment on the same hardware. This works pretty well, too, assuming there is no VM escape attack vector (which is quite rare, and even less likely to be chained to a Wireshark exploit, so let’s not go crazy here), but it requires you to fire up the VM whenever you need to analyze something. Still, if you have to assume your Wireshark is – or even might be – a target, this is the most common way to mitigate most of the risk involved.

#2 – disable irrelevant protocol dissectors

I’m not sure if everybody know this, but you can disable the protocol dissectors in Wireshark. E.g. if you know you’re only looking at TCP and UDP over IPv4/IPv6 and Ethernet, you could disable everything else, like I’ve demonstrated in the PCAP Split and Merge post, where I created an additional tshark profile for faster parsing (yes, more secure and faster, yay!):

Figure 2 – Wireshark Enabled Protocols

By disabling all the other protocols you’re drastically reducing the attack surface. You can create a profile for that and switch back and forth easily. And even if you’re enabling more complex but very common protocols like HTTP and HTTPS the chances of their dissectors being vulnerable are far less likely than some obscure protocol nobody has ever heard of (but Wireshark still has a dissector for, of course). If you look some of the CVEs filed for Wireshark recently you can immediately see that they’re for protocols not that many users even need to decode: CVE-2018-16056, CVE-2018-16057 and CVE-2018-16058. Of those the WiFi radio-tap header exploit is probably the most problematic (please, WiFi people, don’t get mad at me, but most users sniff wires, not wireless). Bluetooth is pretty rare compared to what I assume the >98% Ethernet frames people look at in Wireshark. Funny enough Cisco doesn’t even mention disabling the protocol dissectors as a countermeasure (“Safeguard”), which may be a result of the people finding the bugs being users of those specific dissectors, so it didn’t come to mind to just disable them if you don’t need them.

#1 – Run Wireshark as non-privileged user

I’m not saying you can’t run bad stuff as a non-privileged users, even if it may take a little privilege escalation in the process. But I really get a headache each time I see someone running Wireshark as root or administrator. Most of the time people do it because they can’t access their network cards for capturing otherwise, which means that their Wireshark capture privilege setup hasn’t been done correctly. Well, here’s how to do that. So if you’re one of those wanting to run Wireshark with root or administrator rights, this is for you:

Final Words

I have, in more than 15 years of working with packet captures, never encountered a file that contained anything designed to attack Wireshark. I have seen Wireshark crash more times than I can count, especially the dreadful 1.0 version, but as far as I can tell none of those crashes were caused by attack packets. And I can’t even tell how many TByte of data I loaded in that time, with billions of packets. Of course it’s possible that I was attacked and didn’t notice, but I don’t think so. And whenever my computer starts to behave in a strange way I investigate it’s communication pattern in a way no attacker has the slightest hope of preventing it – and not with the computer itself, of course. So far I never found any compromise, only bad drivers or other legit software misbehaving. Or Wireshark crashing because of bugs, of course.

In the end, I’m not saying that there isn’t something out there that can successfully attack Wireshark when loading a pcap. But chances are that normal Wireshark users (meaning: developers, network engineers, troubleshooters) will never encounter a file like that. And digital forensics/incident response professionals should be treading carefully anyway, and that includes being careful with any kind of evidence they look at, at all times.