This wiki has been migrated to https://gitlab.com/wireshark/wireshark/-/wikis/home and is now deprecated. Please use that site instead.
Differences between revisions 1 and 22 (spanning 21 versions)
Revision 1 as of 2005-02-08 13:49:50
Size: 2868
Editor: UlfLamping
Comment: first content
Revision 22 as of 2010-02-22 21:29:02
Size: 5998
Editor: JeffMorriss
Comment: epan/dissectors now has more than 1.9 million lines of code (up from 1.0 million previously quoted here)
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
This page collects information about the secure usage of Wireshark.
Line 3: Line 4:
This page should collect information about security topics. <<TableOfContents>>
Line 5: Line 6:
== General == = Introduction =
In recent time, Wireshark was often mentioned in security bulletins about having several security related bugs fixed. This is caused by code reviews of individuals and interested parties and by the effort of the Wireshark team to automatically find bugs. It is expected that this will continue - at least in the near future.
Line 7: Line 9:
In most programs, only parts of a program are directly working with "outside" data (from a file or network), so to avoid security problems, the developer's are doing code reviews about that parts which (hopefully) will eliminate most security problems. While there is currently no known exploit out there to attack Wireshark, this may change one day ...
Line 9: Line 11:
Ethereal is a bit different here, as almost the complete code will work with data from the "outside" (being it live captured or loaded from a file) making a code review on the relevant parts would be a code review of the complete Ethereal code which would be a '''huge''' effort, and not all problems might be found after all. This is making Ethereal more vulnerable to attacks than most other programs. Because of this, special care should be taken to avoid security related problems while running Wireshark or at least to reduce the possible impact.
Line 11: Line 13:
Ethereal is implemented in ANSI C which is vulnerable to security problems like buffer overflows (compared to more secure designed languages like JAVA or C#). ANSI C is used for several reasons, the main reason is perfomance, as Ethereal is often used to work with huge amounts of data. Whether this is a problem for yourself will depend on the situation: A small !SoHo network will probably be less critical compared to a company's 24/7 mission critical web server, capturing data from an internal network is probably more secure than capturing internet traffic, ...
Line 13: Line 15:
A further security problem is that the Ethereal development process includes patches from many different developers (with different levels of programming skills) all around the world, and only a few developers doing the job of reviewing the patches before they are checked in the main source tree. It's not the intention of this page to discuss the opinion of certain persons that the usage of Wireshark itself is "insecure", because you can see network data like transported passwords. BTW: Security through obscurity just doesn't work.
Line 15: Line 17:
'''Conclusion''': The current development model won't change for several reasons, so if there are concerns about the mentioned security problems, different approaches avoiding the drawbacks of these problems should be taken. = Why is Wireshark so buggy? =
Well, it's not that buggy as it may seem. Recent automated code inspections showed a much lower defect rate compared to other known open source programs (the defect rate of closed source programs is not known but may be even higher). Unfortunately most bugs found in the Wireshark code are security related so they are mentioned in the security bulletins.
Line 17: Line 20:
The best way might be to run Ethereal in a user account which can't do any real harm. As on some platforms live capturing from the network needs administration privileges, additional steps have to be taken, just see below. In most programs, only small sections of code work directly with "outside" data (e.g. from a file or network). By focusing on these small sections during code reviews, developers can eliminate most security problems.
Line 19: Line 22:
== Windows == Wireshark is different. The vast majority of its code base deals directly with data from the "outside", so a code review on the relevant parts would cover most if not all of the complete Wireshark code. Running "wc -l epan/dissectors/*.[ch]" returns over 1,900,000 lines of code that's expected to handle fresh-off-the-wire data! Auditing all of this would be a '''huge''' effort, and may not guarantee success.
Line 21: Line 24:
The WinPcap (NPF) driver is loaded by Ethereal when it starts to capture live data. Wireshark is implemented in ANSI C, which is vulnerable to security problems like buffer overflows (compared to more securely designed languages like Java or C#). ANSI C is used for several reasons; the main reason is performance, as Wireshark is often used to work with huge amounts of data. Another reason is that implementations of other languages might not be as commonly available on all the platforms Wireshark supports.
Line 23: Line 26:
This loading requires administrator privileges. Once the driver is loaded, every local user can capture from it until it's stopped again. To make things worse, the Wireshark development is done in an "experimental character" as new protocols are added all the time and existing ones are greatly improved, the main reason that Wireshark has gained such a wide support of protocols. The developers providing code to Wireshark (literally hundreds) have very divergent programming experience, from advanced networking specialists to novice programmers, making it more likely that new bugs get in.
Line 25: Line 28:
To be secure (at least in a way), it is recommended that the administrator should always running in a user account, and only start processes that '''really''' need the administrator privileges. As a result, Wireshark is more vulnerable to attacks than most other programs.
Line 27: Line 30:
So using Ethereal running in a user account could look like: = Which user actions are critical? =
Having a bug in the GUI code (e.g. a crash while printing) can be quite annoying. However, these bugs are usually not security related as they cannot be triggered from the outside.
Line 29: Line 33:
Start the NPF driver: The most critical action is analyzing packets when they are read in. The following actions will call into the myriad lines of dissector code with data coming from the "outside":
Line 31: Line 35:
{{{runas /u:administrator "net start npf"}}}  * Open a capture file
 * If "Update list of packets in real time" is used while capturing
 * if "Update list of packets in real time" is ''not'' used after capture stops
Line 33: Line 39:
Start Ethereal and work with it, including capturing, until the specific job is finished. = Administrator/root account not required! =
Many Wireshark users think that Wireshark requires a root/Administrator account to work with.
Line 35: Line 42:
Stop the NPF driver again: That's not a good idea, as using a root account makes any exploit far more dangerous: a successful exploit will have immediate control of the whole system, compromising it completely.
Line 37: Line 44:
{{{net stop npf}}} First of all, most Wireshark functions can always be used with a (probably very limited) user account. In particular, the protocol dissectors which have shown most of the security related bugs do not need a root account!
Line 39: Line 46:
This way, it's a lot more secure than running with the administrator account. However, while doing this, any local user can also capture from the network. This might not be desireable, but this can't be currently circumvented. Please note that this is not a limitation of the Ethereal implementation, but of the underlying WinPcap driver. Only capturing (and gathering capture interface information) may require a root account, but even that can usually be "circumvented", see CaptureSetup/CapturePrivileges for details how to do so.

= Protect Yourself! =
There are some things you can do:

 * '''Always update to the latest Wireshark version''' available as bugs are fixed frequently. You can join the announce mailing list to stay informed about new versions.
 * '''Don't run Wireshark as root/Administrator!''' See CaptureSetup/CapturePrivileges for details how to do so.
 * '''Analyze capture files in an uncritical environment.''' You may create a special (limited) user account or even use a dedicated machine for this task.
 * Use a small capture tool which is less likely affected by security bugs, e.g.: tcpdump or dumpcap) and transfer the capture file to the uncritical environment mentioned above
 * The SampleCaptures wiki page collects capture files for automated tests. If you have a capture file with an undecoded protocol help the developers and attach the file to that page.

= Help is on the way! =
The Wireshark developers agree that the current situation isn't actually satisfying.

Current effort is spent in several ways to improve Wireshark in that regard:

 * Automated tests uncover previously unknown bugs
 * code reviews take place
 * potential unsecure functions are removed from the code
 * ... and many other things

You'll find more information about that effort at the [[Development/Security]] page.

As it's a lot of effort involved in the above tasks, it's unpredictable when they'll be finished (if ever).

Security

This page collects information about the secure usage of Wireshark.

Introduction

In recent time, Wireshark was often mentioned in security bulletins about having several security related bugs fixed. This is caused by code reviews of individuals and interested parties and by the effort of the Wireshark team to automatically find bugs. It is expected that this will continue - at least in the near future.

While there is currently no known exploit out there to attack Wireshark, this may change one day ...

Because of this, special care should be taken to avoid security related problems while running Wireshark or at least to reduce the possible impact.

Whether this is a problem for yourself will depend on the situation: A small SoHo network will probably be less critical compared to a company's 24/7 mission critical web server, capturing data from an internal network is probably more secure than capturing internet traffic, ...

It's not the intention of this page to discuss the opinion of certain persons that the usage of Wireshark itself is "insecure", because you can see network data like transported passwords. BTW: Security through obscurity just doesn't work.

Why is Wireshark so buggy?

Well, it's not that buggy as it may seem. Recent automated code inspections showed a much lower defect rate compared to other known open source programs (the defect rate of closed source programs is not known but may be even higher). Unfortunately most bugs found in the Wireshark code are security related so they are mentioned in the security bulletins.

In most programs, only small sections of code work directly with "outside" data (e.g. from a file or network). By focusing on these small sections during code reviews, developers can eliminate most security problems.

Wireshark is different. The vast majority of its code base deals directly with data from the "outside", so a code review on the relevant parts would cover most if not all of the complete Wireshark code. Running "wc -l epan/dissectors/*.[ch]" returns over 1,900,000 lines of code that's expected to handle fresh-off-the-wire data! Auditing all of this would be a huge effort, and may not guarantee success.

Wireshark is implemented in ANSI C, which is vulnerable to security problems like buffer overflows (compared to more securely designed languages like Java or C#). ANSI C is used for several reasons; the main reason is performance, as Wireshark is often used to work with huge amounts of data. Another reason is that implementations of other languages might not be as commonly available on all the platforms Wireshark supports.

To make things worse, the Wireshark development is done in an "experimental character" as new protocols are added all the time and existing ones are greatly improved, the main reason that Wireshark has gained such a wide support of protocols. The developers providing code to Wireshark (literally hundreds) have very divergent programming experience, from advanced networking specialists to novice programmers, making it more likely that new bugs get in.

As a result, Wireshark is more vulnerable to attacks than most other programs.

Which user actions are critical?

Having a bug in the GUI code (e.g. a crash while printing) can be quite annoying. However, these bugs are usually not security related as they cannot be triggered from the outside.

The most critical action is analyzing packets when they are read in. The following actions will call into the myriad lines of dissector code with data coming from the "outside":

  • Open a capture file
  • If "Update list of packets in real time" is used while capturing
  • if "Update list of packets in real time" is not used after capture stops

Administrator/root account not required!

Many Wireshark users think that Wireshark requires a root/Administrator account to work with.

That's not a good idea, as using a root account makes any exploit far more dangerous: a successful exploit will have immediate control of the whole system, compromising it completely.

First of all, most Wireshark functions can always be used with a (probably very limited) user account. In particular, the protocol dissectors which have shown most of the security related bugs do not need a root account!

Only capturing (and gathering capture interface information) may require a root account, but even that can usually be "circumvented", see CaptureSetup/CapturePrivileges for details how to do so.

Protect Yourself!

There are some things you can do:

  • Always update to the latest Wireshark version available as bugs are fixed frequently. You can join the announce mailing list to stay informed about new versions.

  • Don't run Wireshark as root/Administrator! See CaptureSetup/CapturePrivileges for details how to do so.

  • Analyze capture files in an uncritical environment. You may create a special (limited) user account or even use a dedicated machine for this task.

  • Use a small capture tool which is less likely affected by security bugs, e.g.: tcpdump or dumpcap) and transfer the capture file to the uncritical environment mentioned above
  • The SampleCaptures wiki page collects capture files for automated tests. If you have a capture file with an undecoded protocol help the developers and attach the file to that page.

Help is on the way!

The Wireshark developers agree that the current situation isn't actually satisfying.

Current effort is spent in several ways to improve Wireshark in that regard:

  • Automated tests uncover previously unknown bugs
  • code reviews take place
  • potential unsecure functions are removed from the code
  • ... and many other things

You'll find more information about that effort at the Development/Security page.

As it's a lot of effort involved in the above tasks, it's unpredictable when they'll be finished (if ever).

Security (last edited 2015-08-22 15:51:05 by RuelBorais)