wireshark: yet another pile of dissector flaws

Posted Oct 6, 2014 14:36 UTC (Mon) by raven667 (subscriber, #5198)
In reply to: wireshark: yet another pile of dissector flaws by dlang
Parent article: wireshark: yet another pile of dissector flaws

But it's a good point to note that after all these years and CVE numbers, how could they not think about the problem? My guess is that the project doesn't see the wireshark attack vector as particularly likely and so the risk is not serious. Otherwise they'd create a validating bytecode interpreter for processing packet data and port their decoders to it, or they'd separate out the decoders from the UI and create a heavily sandboxed sub-process to process any dirty data.

to post comments

wireshark: yet another pile of dissector flaws

Posted Oct 6, 2014 15:24 UTC (Mon) by dlang (guest, #313) [Link] (17 responses)

I believe that they do say that running live as root is bad and that you should be running as a non-privileged user against capture files.

While this doesn't eliminate the risk, it does substantially reduce the impact (especially if the machine you are reviewing the files on is on a different network than where the data was captured)

wireshark: yet another pile of dissector flaws

Posted Oct 6, 2014 16:56 UTC (Mon) by malor (guest, #2973) [Link] (16 responses)

That just strikes me as an excuse to avoid writing good code. Blame the user, instead of the faulty code.

In essence, they're saying that their tool isn't safe to use for the purpose it's designed for, analyzing network traffic, and that they're perfectly okay with that.

From a security perspective, the wireshark people might be the worst team in open source.

wireshark: yet another pile of dissector flaws

Posted Oct 6, 2014 17:27 UTC (Mon) by pizza (subscriber, #46) [Link] (14 responses)

That's not fair to Wireshark (the project).

Most dissectors are contributed by folks who want to be able to decode $random_protocol they're developing in a lab. It's written according to the protocol specs (if there even are any) and generally assumes that nothing outside the spec will occur.

These vulnerabilities that keep popping up are primarily in the long tail of obscure protocols, not in the core wireshark code that is pretty solid.

Meanwhile, taking advantage of a particular dissector's vulnerabilities would take some seriously targeted attacks.

wireshark: yet another pile of dissector flaws

Posted Oct 6, 2014 17:54 UTC (Mon) by malor (guest, #2973) [Link] (13 responses)

>Most dissectors are contributed by folks who want to be able to decode $random_protocol they're developing in a lab.

It doesn't really matter who wrote it, they're still shipping it. It's not like anyone is putting the thumbscrews to them.

>would take some seriously targeted attacks

That's true of many attacks, yet it doesn't seem to stop them from being used.

When they're actually saying that you shouldn't use their code to do what it's intended to do, you know there's a huge problem with the project.

wireshark: yet another pile of dissector flaws

Posted Oct 6, 2014 18:27 UTC (Mon) by bronson (subscriber, #4806) [Link] (12 responses)

To understand, maybe you could put yourself in their position. Let's say someone just emailed you a dissector that looks pretty decent. Do you err on the side of inclusiveness, or do you reject it? Time is far too limited: you're not able to rewrite it or analyze it closely. It's one or the other.

If you include it, others will be able to use the dissector and contribute to it, continue fixing bugs and closing holes, and the project as a whole benefits more people. The downside is, of course, a few more CVE numbers and, if anyone's carelessly snooping traffic that might have passed through the NSA, there's a tiny but nonzero chance the machine they're using gets owned.

If you reject the dissector, everyone has to write their own, which will be of far worse quality and capability, and Wireshark will be useful to fewer people. Plus snooping APTs will still be really REALLY dangerous.

> That's true of many attacks, yet it doesn't seem to stop them from being used.

Got any evidence to back up this claim? Stuxnet-scale scenarios are not as common as you imply.

> When they're actually saying that you shouldn't use their code to do what it's intended to do

Again, got evidence of anyone on the Wireshark team saying this? Lots of apps say to not run as root.

wireshark: yet another pile of dissector flaws

Posted Oct 6, 2014 19:25 UTC (Mon) by raven667 (subscriber, #5198) [Link] (1 responses)

> It's one or the other.

That sounds like a false choice. Since protocol decoders seem to be a never ending stream of fun it makes sense to work on infrastructure to limit the amount of damage that can be done by a malfunctioning decoder, by sandboxing or by providing a safe implementation toolkit so that decoder writers can't introduce security bugs.

> Lots of apps say to not run as root.

That's kind of a red herring, I would guess that a significant fraction if not majority of wireshark users are running the GUI on a different machine entirely than where the packet captures are created, and the consequence of a security break is access to the workstations of network engineers who probably have very privileged access, from the user account that the attacker now controls. Root access not required for this to be a problem.

> Stuxnet-scale scenarios are not as common as you imply.

I have to grant that if your plan to get access to some major network is to send malformed traffic in the hopes that an engineer will pull a packet capture on to their desktop, you probably need a better plan, I suppose you could call in trouble tickets to increase your chances but this will be a hard attack to pull off in practice, though not impossible.

wireshark: yet another pile of dissector flaws

Posted Oct 6, 2014 22:32 UTC (Mon) by bronson (subscriber, #4806) [Link]

I agree, the way I worded it sounds like a false dichotomy. I hate to oversimplify but I also did't want to write a book on large scale project management.

> it makes sense to work on infrastructure to limit the amount of damage that can be done by a malfunctioning decoder, by sandboxing or by providing a safe implementation toolkit

Not if you want to ship anything this decade. How many man-hours have been sunk into Chrome's sandboxing? (and they're still working on it). How many resources does Wireshark have compared to Chrome?

I also want my soldering iron hot and my kitchen knives sharp. This means that they must all be used with training and caution. Sure, I would dearly love safer tools but, so far, this is the best that the experts have managed with the resources they had.

And it's really not that bad.

wireshark: yet another pile of dissector flaws

Posted Oct 6, 2014 20:41 UTC (Mon) by malor (guest, #2973) [Link] (6 responses)

>Got any evidence to back up this claim? Stuxnet-scale scenarios are not as common as you imply.

Actually, I'd say the burden of proof is on you, since I never mentioned anything about Stuxnet scale. What I said is that targeted attacks definitely get used. Can you prove otherwise?

>Again, got evidence of anyone on the Wireshark team saying this? Lots of apps say to not run as root.

Sure, but *when that app needs root to run*, then that's a completely bogus restriction. "Our software is safe to use, as long as you don't actually use it in the major mode for which it was designed."

It's a weak, lame cop-out.

If you're going to be releasing code that needs root to run, then you should absolutely err on the side of not including contributed code you haven't audited very carefully.

Plus, for god's sake, it's a program that's designed to intercept and analyze unknown data from unknown sources. Extreme caution should be the order of the day with any program that can be exposed to hostile traffic... and wireshark is one of the first tools that often get deployed to analyze that type of traffic. It's supposedly one of the first responders to security problems; there aren't that many programs where security matters more.

As is, wireshark is like a firetruck that explodes if an ember falls on it.

And, as raven points out, particularly with the typically dismal state of local security in the Linux kernel, even if you rig up the lame "capture as root, analyze on another computer" scenario that they apparently think is an okay prescription for their security problems, getting any account at all on a network engineer's workstation is very dangerous. Once you have an account, getting root is frequently quite easy.

wireshark: yet another pile of dissector flaws

Posted Oct 6, 2014 22:15 UTC (Mon) by bronson (subscriber, #4806) [Link] (3 responses)

No it does NOT need root to run. Whenever I used it, I pulled dumps from some virtual interface who-knows-where, and then ran it -- as my user -- over the dumpfiles.

If you're running it as root, presumably you're doing it on a private network anyway, and therefore you don't have much to worry about or, at the very least, you know what threats you're facing.

> As is, wireshark is like a firetruck that explodes if an ember falls on it.

It seems to me like you're being a firetruck that explodes if an ember falls on it? Lots of vulnerabilities does not imply lots of danger.

Clearly you feel very strongly. Maybe you could direct some of that energy into strengthening the dissectors? It's an amazingly huge coding problem and can use all the man hours it can.

wireshark: yet another pile of dissector flaws

Posted Oct 19, 2014 2:42 UTC (Sun) by ccurtis (guest, #49713) [Link] (2 responses)

No it does NOT need root to run. Whenever I used it, I pulled dumps from some virtual interface who-knows-where, and then ran it -- as my user -- over the dumpfiles.

I don't understand your argument. Instead of exploiting root, now it exploits your user account. This makes you feel better for some reason?

wireshark: yet another pile of dissector flaws

Posted Oct 19, 2014 3:05 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]

Why wouldn't it?

wireshark: yet another pile of dissector flaws

Posted Oct 19, 2014 3:23 UTC (Sun) by pizza (subscriber, #46) [Link]

> I don't understand your argument. Instead of exploiting root, now it exploits your user account. This makes you feel better for some reason?

Serious question. Just what, exactly, is the threat vector here?

I'm not saying that it's impossible to exploit, just that it would take a seriously motivated attacker specifically targeting you for it to be worth their effort -- and that's just for a maliciously crafted capture file. If the attack involved live packet injection into your local network segment, you've already lost.

...Maybe I lack imagination or paranoia, but the only scenarios I can come up with make Schneiner's Movie Plot Challenges look downright plausible in comparison.

wireshark: yet another pile of dissector flaws

Posted Oct 6, 2014 22:53 UTC (Mon) by bronson (subscriber, #4806) [Link]

Sorry, missed this.

> Actually, I'd say the burden of proof is on you, since I never mentioned anything about Stuxnet scale. What I said is that targeted attacks definitely get used. Can you prove otherwise?

Sure. As far as I know, targeted attacks have not successfully been used against Wireshark yet. You're the one saying it's such a big problem so maybe post some evidence demonstrating why?

As pizza said, it would be really REALLY difficult to target Wireshark. Not impossible, just requiring an unbelievable amount of preparation. I shortened that concept to to "Stuxnet-scale" but you can insert whatever APT name you want.

Yes, I agree, it's a problem. However, everything is a trade-off, and this is how the devs have chosen to proceed. If Wireshark scares you so deeply, don't worry: it's not installed by default.

wireshark: yet another pile of dissector flaws

Posted Oct 7, 2014 0:00 UTC (Tue) by pizza (subscriber, #46) [Link]

> If you're going to be releasing code that needs root to run, then you should absolutely err on the side of not including contributed code you haven't audited very carefully.

I suggest you audit your understanding; wireshark has, for a very long time now, separated the *capture* component (which requires elevated privileges for some sorts of capture operations) from the *decoding* component into separate processes.

> It's supposedly one of the first responders to security problems; there aren't that many programs where security matters more.

By all means help them out, they're always in need of help. Or are you volunteering additional work on others?

wireshark: yet another pile of dissector flaws

Posted Oct 6, 2014 20:44 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (2 responses)

What about hiding new dissectors behind a "enable experimental dissectors" button? I also agree that seccomp should be used here. Other than read (or, better, just use a memory buffer interface), what syscalls would be needed?

wireshark: yet another pile of dissector flaws

Posted Oct 6, 2014 21:03 UTC (Mon) by dlang (guest, #313) [Link] (1 responses)

I expect that the majority of dissectors would never graduate from behind the button, and so it would become a "enable experimental dissectors to get anything useful"

wireshark: yet another pile of dissector flaws

Posted Oct 6, 2014 21:09 UTC (Mon) by malor (guest, #2973) [Link]

>I expect that the majority of dissectors would never graduate from behind the button, and so it would become a "enable experimental dissectors to get anything useful"

I think you're overstating that by a huge degree, but even if you're completely correct, that would still be better than what they're doing now.

wireshark: yet another pile of dissector flaws

Posted Oct 6, 2014 17:54 UTC (Mon) by dlang (guest, #313) [Link]

remember that the dissectors are written by a much wider group of people than the core wireshark team. the dissectors are then contributed and distributed along with the core.

As a result, the dissectors are only as good as people who care about that particular type of traffic

also note that these flaws are almost always 'crash' or 'loop/DoS' types of things. That says that the core wireshark team is doing a fairly good job of sandboxing the dissector code to limit the damage it can do.

Changing this to be in some other language would not prevent problems in the code from either causing exceptions or infinite loops.