|
|
Subscribe / Log in / New account

Wireshark 2.0: Now with Qt

By Jake Edge
December 9, 2015

The headline feature for Wireshark 2.0, which was released on November 18, is the switch away from GTK+ and to the Qt framework, but there is more to it than just that. The bulk of the changes to Wireshark—the venerable free-software network packet sniffer that started out as Ethereal in 1998—come under the heading of user-interface improvements, but that leads to some improved functionality as well.

The switch to Qt was announced back in October 2013, so it has taken around two years to complete the switch. The main reason behind the change was to better support Mac OS X, which is something of second-tier platform for GTK+. In addition, Qt will make Android and, possibly, iOS versions possible as well. Based on a blog post from Wireshark founder Gerald Combs, Qt has also helped make the interface function "much more smoothly".

Combs noted that the new interface looks largely the same as the previous version, which is intentional.

The screenshots above are similar because we’ve also tried to ensure that the new UI is familiar to current users. The features you’re used to are still there and in the same place (or at least nearby).

[Wireshark]

At its core, Wireshark provides a way for users to capture packets on the local network, then to display them for analysis. The basic three-pane display, with a pane for a list of packets captured (i.e. the "Packet List" pane) and two that show details of the currently selected packet, looks much the same. The packet-specific panes show a decoded version of the packet that splits out various fields in it (Packet Details), while the other shows a hex and ASCII version of the packet (Packet Bytes). There is also a toolbar, display filter entry box, and a menu at the top (as seen at right for 2.0.0rc2 from Combs's post).

[Scrollbar]

There are some things that have changed in the analysis interface, however. Packets related to the one selected in the packet list now have icons to indicate that status. For example, DNS requests and replies have left and right arrows and TCP packets that have been acknowledged have a check mark next to them. In addition, the packet list scrollbar shows a "minimap" of the color of packets nearby in the list—similar to the minimaps in modern text editors. When combined with rules that display different types of packets in various colors, it can help find more interesting portions of the captured packets. The minimap from the screen shot above can be seen at left.

In a webinar [YouTube] given on November 12, Combs and Laura Chappell demonstrate some of the features in the new interface. Many things have been streamlined in the Qt-based interface, they said. But, the GTK+ interface will still be supported until the next stable release, which will be 2.2—odd minor numbers are for development releases.

Some of the examples shown in the webinar were things like an improved interface to choose a saved filter to apply to a capture. Previously that required bringing up a separate window that listed all of the saved filters to choose from; now that can be done directly from a menu just to the left of the filter entry box in the main window. Hiding and showing columns in the packet list can also be chosen directly from a menu that comes up when right-clicking the column headings. The interface for setting coloring rules has also been improved so that colors can be chosen from a "picker" rather than having to enter color names.

There has also been some cleanup done in the toolbar to remove clutter, as well as rearranging the main menus somewhat to put functions in more natural locations. For the graphs and statistics windows, there is no longer a step to choose settings before seeing the output; those settings are available at the bottom of the window, so if the standard output with no filter is all that's needed, users get that immediately.

There are many more keyboard shortcuts in Wireshark 2. The full list of those shortcuts can be found from the "Help" menu. In addition, individual windows have their own shortcuts, which can be listed from the window itself.

The capture screen, which initiates the packet capture process, has been streamlined as well. There are now small graphs of packet activity for each interface (called sparklines) that can be double-clicked to start a capture on that interface. Those can give users a quick idea of how much traffic is being seen on each interface in the system. Many of the options in the somewhat busy GTK+ capture window have moved to a separate options window (which has its own sparklines).

There is plenty more to the interface that is shown in the hour-long webinar. It is worth a look for those interested in more information. A zip archive of the trace files used in the demonstration are available as well.

Wireshark 2 has been localized for seven languages for the release. Chinese, English, French, German, Italian, Japanese, and Polish versions are available and more translations are currently being worked on. The project uses a Transifex site for that translation work and Combs invited those interested to join in the efforts.

In addition to the upgraded interface, lots of bugs were squashed in the release, including a number of security holes. Over the years, Wireshark has gotten something of a bad reputation for its security track-record. As the Wireshark security page indicates, the program is tasked with dealing with enormous amounts of user-supplied data using "dissectors" to parse and decode many different formats, including experimental ones. That's not an excuse for the large numbers of bugs that continue to be found, but most of the code in Wireshark is in the dissectors, which means that the bulk of the bugs found will be security issues.

There are a number of things that can be done to reduce the damage that a capture (or, worse, an attacker-supplied capture file) can do in the presence of dissector bugs. For example, Wireshark should never be run as root and captures can be done with a simpler program (e.g. tcpdump) and then imported into Wireshark running in a limited user account or dedicated machine (virtual or otherwise). In addition, the page lists several ongoing efforts to find and remove bugs from the code, which are further fleshed out on a dedicated security development page.

Overall, Wireshark 2 looks like a solid release that brings a lot of interface improvements. That should make it easier to work with and allow users to be more productive in their network troubleshooting and analysis.



to post comments

Priviledge Seperation

Posted Dec 10, 2015 12:35 UTC (Thu) by pwfxq (subscriber, #84695) [Link] (10 responses)

Maybe Wireshark should copy a technique used by other programs and implement privilege separation when capturing packets.

Priviledge Seperation

Posted Dec 10, 2015 13:00 UTC (Thu) by NAR (subscriber, #1313) [Link]

I'm not sure that would help much. It is already possible to capture the packets via tcpdump, then load it in unprivileged wireshark - but if that unprivileged user account is used to do online banking, then it might be a more interesting target than the root account...

Priviledge Seperation

Posted Dec 10, 2015 13:14 UTC (Thu) by pizza (subscriber, #46) [Link] (1 responses)

Wireshark has separated out capture from the UI for many, many years now.

Priviledge Seperation

Posted Dec 12, 2015 9:18 UTC (Sat) by Lekensteyn (guest, #99903) [Link]

This is true, the capture process ("dumpcap") is a separate process which is run by Wireshark/tshark to capture packets. This process does not need setuid root, it is sufficient to give it CAP_NET_RAW and CAP_NET_ADMIN capabilities. See https://wiki.wireshark.org/CaptureSetup/CapturePrivileges... for instructions.

Priviledge Seperation

Posted Dec 10, 2015 13:20 UTC (Thu) by jlayton (subscriber, #31672) [Link]

If you're running on an OS that has file capabilities, then you don't need to be root to run a capture. On recent Fedora, for instance you just need to be in the "wireshark" group and you can run a live capture as an unprivileged user.

Priviledge Seperation

Posted Dec 10, 2015 17:59 UTC (Thu) by iabervon (subscriber, #722) [Link] (3 responses)

It might be interesting to consider isolating the packet analysis from the UI, and running the packet analysis in a process without the ability to use nearly any system calls. Even without any special privileges, it's easy to imagine an attack that uses a bug in a dissector to send the whole packet dump somewhere over TOR, which could reveal a bunch of local network secrets in response to having attacker-generated packets in the same dump.

Priviledge Seperation

Posted Dec 10, 2015 20:00 UTC (Thu) by bronson (subscriber, #4806) [Link] (2 responses)

I had the same thought... If ever there was a case for tight sandboxing, dissectors are it.

I assume the catch is that Wireshark is cross-platform and sandboxing is not. Very very not.

Priviledge Seperation

Posted Dec 10, 2015 22:33 UTC (Thu) by johill (subscriber, #25196) [Link] (1 responses)

Writing dissectors is already a huge pain ;-)
Seriously though - it could probably be done since the dissectors interact with an abstract representation of the parse tree, but you'd have to serialize that across some kind of protocol which is likely quite awful ...

I think the cross-platform angle seems a bit of a red herring; once you've split it out to a separate process you could get the security where it's supported?

Priviledge Seperation

Posted Dec 11, 2015 15:27 UTC (Fri) by raven667 (subscriber, #5198) [Link]

As far as cross platform sandboxing, it seems the browser vendors have lead the way, Chrome was designed around the needs of sandboxing and has researched it thoroughly on all supported operating systems, so using that as a template to start from seems the smart move.

It seems you only need a file descriptor in/out, input would be pcap data, output would have to be structured for consumption by the Wireshark UI, which provides its own attack surface and potential for failure, but it should be lower than that of the dissectors themselves, even as the dissectors are re-written in a safer way. How is that done in browser land, what validation does the display process have of data being fed from the parser?

Privilege Seperation

Posted Dec 11, 2015 7:34 UTC (Fri) by robbe (guest, #16131) [Link] (1 responses)

I’m not too worried about capturing. See other answers.

More interesting at the moment would be privilege-seperating the dissectors from the GUI. They are a prime example where even simple seccomp could do wonders.

Privilege Seperation

Posted Dec 12, 2015 19:18 UTC (Sat) by jmayer (guest, #595) [Link]

IIRC, there was a project called echild. The code is still part of the source but it was never built by default. The code quality in that directory is sad.

Wireshark 2.0: Now with Qt

Posted Dec 15, 2015 5:59 UTC (Tue) by ploxiln (subscriber, #58395) [Link] (3 responses)

I've used a custom compiled 1.12.x with the GTK+3 UI on OS X for about a year. It's a bit tricky, but homebrew makes it managable, to compile all the dependencies with the right flags. You can end up with a full-featured non-X11 wireshark 1.12.x that looks good and works well.

It's disappointing that the main Wireshark site never offered a non-x11, gtk+3 OS X build.

I'm sure they had other reasons to want to do a UI re-write with QT though, and I don't think less of them for that.

Wireshark 2.0: Now with Qt

Posted Dec 17, 2015 8:54 UTC (Thu) by thumperward (guest, #34368) [Link] (1 responses)

GTK3 has never had the development resources to be a first-class citizen for anything except Linux. Ten years ago GTK was a genuinely compelling prospect as a cross-platform UI toolkit, but since then there's been a one-way trend even across free software projects. And Qt is used by literally every cross-platform proprietary application I use now.

Wireshark 2.0: Now with Qt

Posted Dec 17, 2015 13:22 UTC (Thu) by jospoortvliet (guest, #33164) [Link]

... And exceedingly often also by the open source ones. Good with me, gtk 2 is fine but often fro 3 apps stick out like a sour thumb.

Wireshark 2.0: Now with Qt

Posted Dec 18, 2015 23:49 UTC (Fri) by jmayer (guest, #595) [Link]

There were quite a few reasons, I tried to explain a few of them at phoronix:
http://www.phoronix.com/forums/forum/software/general-lin...
It's mostly about stable APIs and a bit about multi plaform maintenance.


Copyright © 2015, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds