Category Archives: Announcement

The Cloudflare Incident And Its Impact On Wireshark.org

Cloudflare recently announced a security incident that potentially impacts anyone who visited various wireshark.org and winpcap.org sites for the past six months.

What happened?

Cloudflare is a popular service that provides content delivery, DDoS protection and DNS services for web sites.

A software bug Cloudflare’s servers leaked potentially sensitive information. Some of that information ended up in caches all over the Internet. At Google, Microsoft, your ISP, your company’s or university’s proxy servers, and elsewhere. Due to the randomness and distributed nature of the bug, it’s difficult to know what the full impact is. Cloudflare provides the following estimate:

“The greatest period of impact was from February 13 and February 18 with around 1 in every 3,300,000 HTTP requests through Cloudflare potentially resulting in memory leakage (that’s about 0.00003% of requests).”

The bug was introduced on September 22, 2016 and fixed on February 18th, 2017.

The Google Project Zero bug describing the issue in detail can be found at https://bugs.chromium.org/p/project-zero/issues/detail?id=1139

Cloudflare’s incident report can be found at https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/

The initial Hacker News discussion can be found at https://news.ycombinator.com/item?id=13718752

Was Wireshark affected?

The following wireshark.org and winpcap.org sites were behind Cloudflare proxies during the period in question:

  • ask.wirehsark.org
  • blog.wireshark.org
  • bugs.wireshark.org
  • sharkfest.wireshark.org
  • sharkfesteurope.wireshark.org
  • wiki.wireshark.org
  • www.wireshark.org
  • www.winpcap.org

Wireshark’s download servers (*.dl.wireshark.org), buildbot.wireshark.org and code.wireshark.org were not behind Cloudflare.

I browsed to a one of the sites listed above between September 22nd, 2016 and February 18th, 2017. Am I affected?

The chances are slim, but those chances are not zero.

Most of the content that we serve is “static” and “public.” That is, it’s the same for everyone and doesn’t contain any sensitive information. The risk exposed by Cloudflare is from dynamic content that contains sensitive information such as the login page on ask, bugs, wiki, etc. Our web sites get frequent requests for static content, but dynamic requests are relatively infrequent.

In a world where everyone has infinite free time I would have no qualms about recommending that everyone with a wireshark.org account change his or her passwords. However, this is the real world and your time is valuable. If you logged in to one of our sites and used a unique password it might not be worth your time to change it. On the other hand, if your professional reputation depends on your ask.wireshark.org score you probably should. If you have any sort of administrative access you definitely should. Most of our users fall into the first category.

If you’re wondering why it looks like I’m downplaying the importance of changing your wireshark.org passwords, see the next question.

I used a web browser, smart phone, or an internet-connected wearable doohickey between September 22nd, 2016 and February 18th, 2017. Am I affected?

I honestly don’t know. The chances are almost certainly not zero.

Cloudflare is a very popular service. At the time of this writing an unofficial list of affected sites is 69 MB and rising. It includes many of the world’s most popular web sites.

If you’re going to spend time changing passwords, doing so for sites that deal with finance, email, DNA testing, dating, and other parts of your personal life probably ranks higher than that for, say, the Wireshark wiki.

Isn’t a vague answer like “the chances are slim but not zero” a frustratingly craptastic one compared to a definitive “yes” or “no”?

Yes, but it’s also the honest and correct one.

Getting Ready for SharkFest ’16

The week leading up to SharkFest is always a busy and hectic time around here, but it’s also exciting. I can’t wait to see everyone, and the talks and labs this year promise to continue our tradition of imparting protocol analysis knowledge and insight.

If you’re sill unsure about attending, perhaps this list of reasons for attending that Laura Chappell recently posted will sway you:

1. Gerald Combs and the Wireshark Developers

Gerald Combs, the creator of Wireshark (formerly Ethereal), and many of the core developers will be there actually working on the code in the Developer’s Den. They will be presenting many of the sessions, joining in on the social events (they are a fun group!) and sharing tips and techniques to improve your analysis process.

2. Wireshark Experts as Presenters and Varied Content Levels

There is no dispute that the presenters at SharkFest are the world-authorities on troubleshooting, security analysis, and network optimization. These are the folks who live in the world at packet-level  and can spot a rogue packet at 50 paces! Through a variety of introductory through advanced lectures and hands-on labs, these presenters will show you some hot Wireshark techniques to speed up your time to resolution.

3. Focus on Wireshark 2

It’s time to move up to Wireshark 2. All the presentations and labs at SharkFest ’16 will be focused around the new version of Wireshark. From new features to new techniques, accelerate your migration to Wireshark 2 by getting an inside look at how the experts work their magic.

4. The Reef at SharkFest

I will be hosting The Reef again at SharkFest. The Reef will host hands-on lab exercises, numerous Wireshark University Certified Instructors, Wireshark experts, and Wireshark Developers. Come in and try your hand at the labs and pick up the SharkFest Packet Challenge. This is a great opportunity to mingle amongst Wireshark gurus and hone your troubleshooting and network forensics skills.

5. Hands-On Labs

Get your hands dirty in one of the lab sessions at SharkFest. This year we have added a 100-seat hands-on classroom to SharkFest. This is in addition to the 300+ seater Hahn auditorium. We will also have numerous lab exercises hosted in the Reef and folks to help out on the more challenging labs.

6. Social Events and Peer Networking

The SharkFest team has put together a Welcome Dinner, Vendor Night Party, “Sake’s Surprise” Dinner, and Closing Reception to give you plenty of time to network with other analysts. The casual atmosphere of the Grand Hall lunch area and the Reef offer plenty of opportunities to meet and mingle with other attendees and the developers.

7. Packet Challenge

Again, you will have the chance to test your skills in the SharkFest Packet Challenge. Pick up the Challenge Worksheet in the Reef and grab the USB stick filled with trace files. Turn in your answers in the Reef by Wednesday evening and join us for the Packet Challenge Awards Ceremony in the closing keynote timeslot.

8. Analysis-Focused Vendors

Vendor night is a highlight of the event. As the band plays and the food sizzles on the grill, visit the vendors who sponsor SharkFest. Each vendor is focused on network analysis, troubleshooting, security, optimization and other related topics. These are the folks we all work with to build the most effective analysis environments possible.

9. Computer History Museum and the Revolution

Considered one of the world’s best collection of historical objects relating to the computer industry, the Computer History Museum is a must-see destination for folks in the tech industry! During SharkFest, you will have time to visit the Revolution exhibit to see history in the making. This is our second year at the Computer History Museum – it’s an amazing venue.

10. Sake’s Surprise

I can’t wait to give you more details on this one. Right now, the surprise is in development. It should really be a highlight at SharkFest ’16. As soon as I’m allowed to spill the beans, I will!

11. Troubleshooting with Wireshark Pre-Conference Class

As an extra here, I will be teaching a 3-day class just before SharkFest. The focus is troubleshooting, troubleshooting, troubleshooting! Get the bundle pricing for SharkFest and the 3-day class at https://sharkfest.wireshark.org/registration16.html.

If you can’t attend SharkFest U.S., these reasons also apply to SharkFest Europe. If you are attending either conference, I’ll see you there!

Cool New Stuff

Hello everybody, we’ve got a handful of miscellaneous announcements for you today. They all just happened to occur within a handful of days, so it made more sense to lump them all into one post.

  • Development version 1.99.1 was released, another milestone on the road to 2.0 and our shiny new Qt interface. You can read the full announcement with release notes here, and download it from the “Development Release” section of here!
  • Tweet tweet! That’s right, we have an official twitter handle now for announcements and the like. It is shared by several of the core developers, but mostly run by our fearless leader Gerald. Follow us @WiresharkNews to find out more!
  • Thanks to the hard work of our Debian maintainer Blint, we now have an Ubuntu PPA (Personal Package Archive) containing the latest stable Wireshark releases pre-built for all the supported Ubuntu releases. If you’ve ever wanted the latest and greatest Wireshark on an older version of Ubuntu, now’s your chance, so get it here.
  • Last but not least (although this one’s older – it actually launched way back in June), our repository now has an official github mirror. Please note that this is a convenience only; pull requests and issues will still go through our existing Gerrit and Bugzilla sites. The github mirror is very much *just* a mirror, but it is handy to have none-the-less.

That’s all we’ve got for you today, hopefully one or more of the above items caught your eye.

Wireshark 1.12 Officially Released!

We are proud to announce the release of Wireshark 1.12.0! This is a fairly significant release for us, as we expect it to be the very last release using the GTK toolkit in the default interface (see this post for our plans to replace it).

Wireshark 1.12 contains a substantial number of fixes and new features, representing just over a year of development effort. Check out the release notes for full information on what’s new and improved, and download it now!

If you have any issues with the new version, please file a report in our bug tracker.

To Infinity and Beyond! Capturing Forever with Tshark

Over the last couple of years that I’ve been involved with Wireshark, one issue has reared its head a significant number of times in a surprisingly varied number of ways. These range from “Capturing with tshark uses more and more memory!” to “I set tshark to capture in the background, and it keeps crashing!” to “How do I set up tshark to capture forever?”

Historically we’ve had no good answer to these complaints – Wireshark and tshark both only do what is called stateful dissection. This means that they store what they’ve seen in memory and use that information to provide additional details about future packets, for example by matching requests with responses. While this provides substantial benefits reassembly of protocols over TCP being probably the most obvious it means that as the amount of traffic increases, so does the amount of memory needed to store all of that state. It also means that there’s no way for tshark to run forever unless you’ve got infinite memory (what’s your secret!?) or no traffic at all.

All of that has just changed. Wireshark and tshark have long had a feature that lets you rotate your packet capture across multiple files, preventing any one file from getting too large; to do this, check out the “-b” flag to tshark. This was handy for systems limited in disk space, but did nothing for the ever-growing memory usage. A few days ago, however, I landed a change in tshark’s master branch that makes it discard its internal state every time the capture rotates to a new file. This has one huge benefit: you can now capture (theoretically) forever with tshark by using the “-b” flag!

Like any experimental change however, it does currently have a number of limitations:

  • State is lost when we switch to a new file, so if two fragments of the same message get split across that file boundary, they will not be reassembled. This is effectively unavoidable – while we considered discarding only very old state, this turns out to be extremely difficult with our current architecture. However, the result is that the dissection you get when capturing with “-b” should actually be closer now to the dissection you get when opening the individual files after the fact.
  • Discarding state can be a surprisingly expensive operation, so captures using this feature in high-traffic environments may see their dissection fall behind when switching to a new file. If you see this, please file a bug report with as much detail as you can provide, and we will try to smooth out the rough edges.
  • Memory usage might still grow a very small amount due to previously-hidden memory leaks now being much more obvious. Again, if you see anything problematic, please file a bug report.
  • This feature is limited to tshark only, it is not available in the graphical Wireshark interface. The graphical interface has to permit scrolling backwards to look at previously dissected packets, so it can’t discard anything until the entire capture is closed. (Edit: This isn’t strictly true – now that I’ve actually checked my assumptions, it should be possible to make the GUI behave the same way. It will take some additional work though.)
  • This feature is limited to the master branch only, it will not be in the upcoming 1.12 release. Given the substantial nature of the change, it was decided that it needed a chance to cook before being released as a “stable” feature. It is, however, present in the 1.99 automated development builds as of this morning.

Please test it out and let us know what you think. Happy capturing!

We’re switching to Qt.

Today I released the next development version of Wireshark, 1.11.0. This marks a major change in the direction of the project. We’re switching our user interface library from GTK+ to Qt. Both libraries make it easy for developers write applications that will run on different platforms without having to rewrite a lot of code. GTK+ has had a huge impact on the way Wireshark looks and feels and on its popularity but it doesn’t cover our supported platforms as effectively as it should and the situation is getting worse as time goes on.

Making such a large change wasn’t an easy decision. It means rewriting thousands of lines of code and requires a lot of careful design. We might be the largest standalone application to make this transition (feel free to correct me below). However, I think it’s well worth it and that it’s important to the long-term direction of the project. Ultimately it came down to one thing:

Wireshark’s job is to show you what’s happening on your network. If it can’t run on your system then it’s not doing that job.

If you’re using Windows, Mac OS X, or Linux Mint we need to support Windows, Mac OS X, and Linux Mint. If you’re using an iPad or a Galaxy Note we need to give you a long, hard, nonplussed stare and think about supporting IOS and Android at some point.

When I started writing Ethereal (Wireshark’s original name) it looked like this:

ethereal-0.2.0

It looked like that on Linux and Solaris. It didn’t look like that anywhere else because those were the only two platforms we supported. I chose GTK+ for the user interface toolkit because it made the most sense. Compared to the options available at the time it had a number of advantages. It was small, light, easy to work with, had an active development team, and had a compatible license. A short time later we added support for Windows. GTK+ had some initial compatibility issues on Windows but it has gotten better over time.

Since then the platform landscape has changed but unfortunately GTK+ hasn’t. Most notably Mac OS X has gained popularity and people are starting to ask about Wireshark for their tablets. GTK+ supports OS X but it’s definitely a second-tier platform, making it hard to install and use. We either have to require X11 (like Inkscape) or use an experimental native GTK+ port (like GIMP). Either way it requires a lot of effort on the part of developers to produce a substandard application for users. With GTK+ Wireshark doesn’t look or act at all like a Mac OS X application:

osx-x11

Qt on the other hand provides a nice, clean user experience on all of the platforms that we currently support. If you install the 64-bit version it now looks like this:

osx-qt

What does this mean for users?

If you’re a power user you should probably keep using the GTK+ flavor for the time being. You should also test the Qt flavor from time to time to see how your workflow will change. Both are installed by default on Windows and Linux.

If you’re running OS X you should use the Qt flavor. For common tasks it should have a better workflow. Again, if it doesn’t we aren’t doing our job.

What does this mean for developers?

If you’re developing a new feature using GTK+ you should stop. You’re very likely wasting your time. If you would like to help with the migration grab the code and start developing.

What works?

Everything under the “File” and “Edit” menus.

You can capture, filter, and inspect traffic.

You can edit preferences.

You can follow streams.

You can view TCP stream graphs.

What doesn’t work?

Everything else. No capture options, I/O graphs, flow graphs, VoIP analysis, etc. We still have a lot of work to do.

Switching to Qt is a long and arduous process but I’m excited about what the future holds.

P.S. Solaris is still supported.

solaris-qt

Fifteen Years

Fifteen years ago I released a little network protocol analyzer. At the time it wasn’t very special. It only dissected five protocols and only ran on Linux and Solaris. I decided to share it with the world and released it as open source. I made use of quite a bit of open source software at that point (and still do), and it seemed like a good way to give back to the community.

Immediately after the release an amazing thing happened I started receiving code from people around the world. They had problems similar to mine and were able to modify the little analyzer to suit their needs. They were also kind enough to contribute those modifications back. Those contributions haven’t stopped to this day and Wireshark has grown into a mature, feature-rich, award-winning network analysis tool. People around the world use it to troubleshoot networks, develop software and protocols, and to learn about networking.

Wireshark has been a source of pride many times over the years but I’m particularly proud of two accomplishments. First, your network is not a black box. This is important inasmuch as our daily lives depend on networks operating efficiently, reliably and securely. Wireshark lets you peer into your network and see how it operates at a low level. It’s also accessible. Anyone can download and run it. Protocol analysis is a fascinating world and if you don’t understand what you’re looking it we have a large community of users and educators that can help you.

Second, it turns out that a protocol analyzer makes a great open source project and Wireshark is an example of open source at its best. People who know a lot about protocols are typically know how to write software. If you provide a platform that allows them to give meaning and context to the bits and bytes that make up network packets they will do so on a massive scale. Wireshark now supports over 1,000 protocols and 140,000 different protocol fields and those numbers keep growing.

We’ve had quite a few challenges in the past and we still do. These days all of your interesting traffic is either off in the cloud or speeding across your LAN at multiple gigabits a second. Wireshark doesn’t run on my tablet and it looks awful on my Macbook. However, these are solvable problems and I’m looking forward to the challenge of fixing them.

When I made that first release I had no idea how big it would become or how much it would impact my life. Wireshark is a great and wonderful thing due to the following people:

  • The development team, who seem to generate an endless stream of brilliance and cleverness.
  • The user community, for their knowledge and enthusiasm, and for putting up with the odd wart here and there.
  • Educators, researchers, developers, and everyone else who help people peer into their networks.
  • My employer for sponsoring the project and being such an awesome place to work, and my co-workers for their passion for network performance.
  • My family and friends, for their support and encouragement over the years.

It’s been a wonderful journey so far and I can’t wait to see what lies ahead. Thank you all.

Sharkfest ’12 Recap

The fifth annual Sharkfest wrapped up a couple of days ago. You are no doubt feeling terrible if you missed it. Don’t despair, you can find a retrospective at the Sharkfest web site. The events team tried to make sure each session was recorded so we should have videos to go along with the slides soon.

As usual I wanted to attend more presentations than physics allowed but unfortunately missed some, so I’m waiting for the retrospective videos along with everyone else. (Hansang Bae observed that this is one of the few conferences where presenters attend other sessions.) Here are some quick notes about the sessions I was able to attend:

Monday’s keynote was delivered by Cliff Stoll. He kept insisting that he didn’t have much to say while simultaneously delivering an informative and entertaining talk.

Steve Riley provided a lot of insights into cloud computing: how it’s changing computing and how it can best be utilized.

Loris Degioanni (aka my boss) gave a great presentation on the new platform API that some people have been working on here at Riverbed. I think this is going to be a must-have once people realize the cool and crazy ways that this can be leveraged.

Wireless was well-represented Thomas D’Otreppe taked about OpenWIPS-ng, his new wireless IPS/IDS project. Metageek’s Ryan Woodings talked about wireless below the packet level. Mike Kershaw and Michael Ossman talked about the development of the Kisbee and Ubertooth adapters, and how you too can design and implement real hardware devices.

Hansang Bae showed modern TCP stacks and network devices can collude to make connectivity really slow, and at a really low level.

Laura Chappell showed off a lot of the new features in Wireshark 1.8. I even learned something you can type a color name (e.g. “bisque3”) into the color picker in the preferences. She also released the second edition of Wireshark Network Analysis. It’s even heavier than the first edition, which I learned first-hand.

I led one session this year, Ask The Experts. We ended up talking about ways to improve Wireshark and a few of the core developers and I discussed these ideas the next day.

We got logs of great feedback on the conference as well. Several people commented that we didn’t have as many devlopment-oriented sessions this year as we have in the past. Maybe we can add more next time.

Wireshark is a great and wondrous thing due to its community. The developers, users, educators, sponsors all play a big role in its development and evolution. I see small reminders of this every day but it becomes abundantly clear each year at Sharkfest.

Thanks to the attendees, presenters, and to the Riverbed events team for creating a wonderful experience. I can’t wait to see what next year’s Sharkfest has in store.

Wireshark and Pcap-ng

When Wireshark 1.8.0 is released in the next few months it will introduce two major features: the ability to capture from multiple interfaces at once and the ability to annotate packets. These features have been on the wishlist for years and they will make Wireshark much more useful. They both share dependency on pcap-ng.

Packet comment example

Packet comment example

Pcap-ng is Wireshark’s new default file format. It is more complex than its predecessor (pcap) but it’s also more flexible. Along with multiple interface types and annotations you can store host information, extended interface information, and much more. Wireshark has had basic support for pcap-ng for several years now and 1.8.0 will bring it to the forefront.

But there’s a catch. Suppose you sit down at a computer with Wireshark 1.7 or 1.8 installed. What file format will Wireshark use by default? Unfortunately the answer is “It depends.” If this is a fresh install of Wireshark on a new computer you’ll get pcap-ng files. If this is an upgrade from 1.6 or below you’ll get pcap files. If the preferences were changed or copied from another machine the default format will be affected as well.

There’s another catch. Suppose you’ve just saved a capture file and you want to read it using tcpdump, Cascade Pilot, Snort, or any of the dozens of other applications that use the classic pcap file format. What will happen? Again, it depends. If that application has been updated to support pcap-ng or if it’s using a recent version of libpcap it will probably work. Otherwise don’t hold your breath.

If you’re a Wireshark user you might want to try a recent build of Wireshark 1.7 to see the new features and new file format in action. If you’re a developer and your application reads pcap files you’re most likely in for some grief. For that I apologize. You should probably investigate adding pcap-ng support now before your users start complaining.

Despite the migration pains the switch to pcap-ng is long overdue and will make Wireshark more useful to more people.

Used Cars and Stub Installers

The Wireshark development team works hard to earn the respect of our users. This includes making sure that downloading and installing Wireshark is as easy and trouble-free as possible. Right now the vast majority of our users can go to www.wireshark.org, follow the big green arrows, and immediately download the appropriate Wireshark package for their platform.

For many years a number of third party sites have also offered Wireshark downloads. Typing “wireshark download” into your favorite search engine will turn up a bunch of them, usually just below links to wireshark.org. These sites are popular and often provide valuable services such as reviews and malware prescreening. They also reside outside the Wireshark ecosystem we don’t link to them and aren’t affiliated with any of them.

"This is the Cadillac of invasive toolbars at a Chevy price!"

Sometimes these sites abuse their relationship with their users. For example a few months ago Download.com started using a stub installer which tries to get you to install various toolbars and who-knows-what-else before it installs the package you ultimately want, much like a sleazy car salesman trying to bundle add-ons you don’t want or need.

This sort of bottom-feeding behavior is harmful to our user community and exploits the goodwill we have with our users. Brian Krebs and Gordon “Fyodor” Lyon describe the problem with much more depth and eloquence than I can.

I sent a request to Download.com to disable their stub installer for Wireshark. They complied, but there are dozens of other download sites. Trying to keep tabs on all of them would result in a never-ending game of Whac-A-Mole.

On behalf of the Wireshark development team I promise to provide easily accessible, direct downloads of Wireshark from wireshark.org just as we always have. If you choose to download Wireshark somewhere else we can’t guarantee that the experience will be free of shenanigans so please be careful.