wireshark: multiple vulnerabilities

Package(s):

wireshark

CVE #(s):

CVE-2015-0559 CVE-2015-0560 CVE-2015-0561

Created:

January 23, 2015

Updated:

February 2, 2015

Description:

From the CVE entries:

Multiple use-after-free vulnerabilities in epan/dissectors/packet-wccp.c in the WCCP dissector in Wireshark 1.10.x before 1.10.12 and 1.12.x before 1.12.3 allow remote attackers to cause a denial of service (application crash) via a crafted packet, related to the use of packet-scope memory instead of pinfo-scope memory. (CVE-2015-0559)

The dissect_wccp2r1_address_table_info function in epan/dissectors/packet-wccp.c in the WCCP dissector in Wireshark 1.10.x before 1.10.12 and 1.12.x before 1.12.3 does not initialize certain data structures, which allows remote attackers to cause a denial of service (application crash) via a crafted packet. (CVE-2015-0560)

asn1/lpp/lpp.cnf in the LPP dissector in Wireshark 1.10.x before 1.10.12 and 1.12.x before 1.12.3 does not validate a certain index value, which allows remote attackers to cause a denial of service (out-of-bounds memory access and application crash) via a crafted packet. (CVE-2015-0561)

Alerts:

openSUSE

openSUSE-SU-2015:0113-1

wireshark

2015-01-23

wireshark: multiple vulnerabilities

Posted Jan 29, 2015 6:18 UTC (Thu) by malor (guest, #2973) [Link] (20 responses)

Ah, lovely, yet more security bugs from wireshark.

If this isn't the worst high-profile free software out there, it's gotta be in the top three.

wireshark: multiple vulnerabilities

Posted Jan 29, 2015 10:58 UTC (Thu) by paulj (subscriber, #341) [Link]

It's amazing that wireshark isn't implementing dissectors in a safe(r) language, running in a safe(r) VM. Still all primarily done in C, right? Madness.

wireshark: multiple vulnerabilities

Posted Jan 29, 2015 12:23 UTC (Thu) by pizza (subscriber, #46) [Link] (18 responses)

As I've often pointed out, in practice it's going to take one hell of a directed effort to successfully exploit someone's system via wireshark. Borking things during a live capture requires raw access to the local network (guess what -- you're already hosed in that case) and even offline you'll have to get someone to open a properly malformed file that's going to need to be very carefully targetted.

Anyway. Saying "someone else should do a ton of work to mitigate this!" isn't going to actually accomplish anything.

wireshark: multiple vulnerabilities

Posted Jan 29, 2015 21:56 UTC (Thu) by malor (guest, #2973) [Link] (17 responses)

>Anyway. Saying "someone else should do a ton of work to mitigate this!" isn't going to actually accomplish anything.

Well, maybe not, but it's still sloppy, poorly done software. It wouldn't need so much work if they'd been careful to begin with.

And maybe it'll accomplish one important thing: remind people that they shouldn't use wireshark, because it's not safe.

wireshark: multiple vulnerabilities

Posted Jan 30, 2015 2:10 UTC (Fri) by bronson (subscriber, #4806) [Link] (16 responses)

What else should they use? Hand dissecting packets with pencil and paper?

wireshark: multiple vulnerabilities

Posted Jan 30, 2015 10:44 UTC (Fri) by paulj (subscriber, #341) [Link] (15 responses)

Lua? Guile? Pick any interpreted language that can provide a modicum of runtime bounds checking and can be plugged into a larger C programme. Hell, you can even do it in C, if you build a bounds-checking buffer abstraction and a set of parsing primitives!

Though, the problem with providing safer runtime abstractions in C, is that then people often ignore them and still go write direct, hand-crafted, pointer-twiddling parsing code, with the inevitable high-rate of security critical bugs.

wireshark: multiple vulnerabilities

Posted Jan 30, 2015 16:04 UTC (Fri) by raven667 (subscriber, #5198) [Link] (14 responses)

I think you are missing the point, the earlier poster recommended not doing packet captures and analysis at all, to avoid using wireshark, which is ridiculous. We can all wish that wireshark was implemented differently but wishes without effort are pretty much worthless. Clearly people who do network analysis aren't so fed up with wiresharks security problems that they are funding development of a replacement, there is no force stopping them from doing so.

wireshark: multiple vulnerabilities

Posted Jan 30, 2015 18:39 UTC (Fri) by malor (guest, #2973) [Link] (13 responses)

The fundamental point is that wireshark is terrible software, not fit for purpose.

You can't even safely use it its primary mode (capturing directly as root, off the wire.) Rather, you have to go through a bunch of painful indirection steps to try to contain the damage when it's exploited.

For a tool that people use for security analysis, I can't imagine anything more damning.

wireshark: multiple vulnerabilities

Posted Jan 30, 2015 18:47 UTC (Fri) by dlang (guest, #313) [Link] (1 responses)

Is capturing the data really it's primary purpose? or is it's primary purpose to help you understand the results of the capture?

It's actually far easier to capture the data with tcpdump than it is to do it with wireshark. And capturing the data isn't where wireshark has it's vulnerabilities, it's when you view the data that you run into the weak points (the many dissector modules written by non-core developers)

wireshark: multiple vulnerabilities

Posted Jan 30, 2015 21:12 UTC (Fri) by paulj (subscriber, #341) [Link]

I use wireshark a lot. It is very useful. I am very painfully aware though how awfully insecure it is every time I use it. I wish I could use wireshark without that bit of stress. Maybe what I really need to do is go repurpose some other code and fashion something out of it to help dissect dumps of the protocols I most commonly look at.

wireshark: multiple vulnerabilities

Posted Jan 30, 2015 20:20 UTC (Fri) by bronson (subscriber, #4806) [Link] (6 responses)

> The fundamental point is that wireshark is terrible software, not fit for purpose.

Except it's a very successful project. Lots of people use it, from the lowly web developer to admin teams for undersea cables. Evidence suggests your fundamental point is wrong: Wireshark is remarkably fit for purpose.

Are there dissectors that you're avoiding using because you think that they're going to subvert your machine?

wireshark: multiple vulnerabilities

Posted Feb 2, 2015 3:58 UTC (Mon) by malor (guest, #2973) [Link] (5 responses)

How about "all of wireshark, because it's not safe to use?"

It is an appallingly insecure piece of software, unsafe to run even as a normal user, much less as root.

Considering that security analysis is one of its primary use cases, and that the ability to do live capture is probably the single largest original design goal, I'd say it has failed very spectacularly at what it set out to do.

People may still use it, but if they're not taking extreme steps to mitigate its vulnerabilities, they are foolish to do so. And most of them probably don't even know they're being foolish.

A notice that "this software isn't safe" doesn't cut it. Writing safe software does.

wireshark: multiple vulnerabilities

Posted Feb 2, 2015 4:59 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

Please, you're welcome to rewrite Wireshark in something safe. Or at least offer a comparable alternative.

The reality is - Wireshark is extremely useful, even though it's not really secure. Exploiting it in reality will be complicated and probably not worth it.

A good way forward would be to sandbox dissectors using seccomp or similar sandboxing technologies.

wireshark: multiple vulnerabilities

Posted Feb 2, 2015 5:01 UTC (Mon) by malor (guest, #2973) [Link] (3 responses)

>Please, you're welcome to rewrite Wireshark in something safe.

Or, I could just not use it, and tell people why.

wireshark: multiple vulnerabilities

Posted Feb 2, 2015 6:01 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

Some of us depend on wireshark for essential work-related duties.

wireshark: multiple vulnerabilities

Posted Feb 2, 2015 6:03 UTC (Mon) by malor (guest, #2973) [Link]

I'm sorry. I wish you had better software available.

wireshark: multiple vulnerabilities

Posted Feb 2, 2015 21:17 UTC (Mon) by bronson (subscriber, #4806) [Link]

It sounds like you have little need for deep packet dissection. If that's the case, who would care about your opinion? Other people without that need?

You could tell people about alternatives you've tried that do the same job and don't have the same potential pitfalls. Now THAT would be useful and interesting.

Until then, please realize that Wireshark is one hell of a useful tool. Saying over and over again, "don't ever use it because small potential of extremely theoretical hax0rs!!" sounds like useless noise.

wireshark: multiple vulnerabilities

Posted Feb 1, 2015 19:32 UTC (Sun) by flussence (guest, #85566) [Link] (3 responses)

Running wireshark as root is not its primary mode - that's why it has a big fat startup warning telling you how *not* to do that, should you try to.

Thunar (to name one of many examples) does exactly the same thing - does that mean it's insecure?

wireshark: multiple vulnerabilities

Posted Feb 2, 2015 2:33 UTC (Mon) by paulj (subscriber, #341) [Link]

Wireshark is insecure in parsing network dumps, regardless of user. You have to go to lengths to run it as a sandboxed user, though even then it'll have access to your X display, most likely. Most people don't do that (I don't, but I really should look into it).

wireshark: multiple vulnerabilities

Posted Feb 2, 2015 3:59 UTC (Mon) by malor (guest, #2973) [Link] (1 responses)

>Running wireshark as root is not its primary mode - that's why it has a big fat startup warning telling you how *not* to do that, should you try to.

That's a bullshit retcon by the developers. They didn't add those warnings until they began to realize just how bad their code was.

And, it should be noted: instead of fixing it.

wireshark: multiple vulnerabilities

Posted Feb 2, 2015 13:48 UTC (Mon) by nix (subscriber, #2304) [Link]

It's not 'bullshit retcon', it's a side-effect of a security improvement, namely privilege-separating the packet capture (which must run as root) from eveything else (which, after that change, no longer needed to).

The warning is there to remind people who were used to the *old* way of running Wireshark, which really was terrifying (run it as root), that this was no longer either necessary or recommended. If they hadn't added that warning, many people would never have noticed the change, and would have continued to expose themselves to more security problems than necessary. What would you suggest they do instead?

(However... the dissectors do seem like an excellent example of something that is comparatively easy to privsep into a separate process and seccomp away from almost everything. They're little more than complicated parsers, a perfect fit for something like seccomp.)