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 10 (spanning 9 versions)
Revision 1 as of 2005-02-08 13:49:50
Size: 2868
Editor: UlfLamping
Comment: first content
Revision 10 as of 2006-01-22 05:24:09
Size: 6735
Editor: UlfLamping
Comment: add some general information, to be able to move this page to the FrontPage
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
This page should collect information about security topics. This page collects information about the secure usage of Ethereal.
Line 5: Line 5:
== General == [[TableOfContents]]
Line 7: Line 7:
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. = Overview =
Line 9: Line 9:
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. In the recent months, Ethereal 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 Ethereal team to automatically find bugs. It is expected that this will continue - at least in the near future.
Line 11: Line 11:
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. While there is currently no known exploit to attack Ethereal out there, this may change one day ...
Line 13: Line 13:
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. Because of this, special care should be taken to avoid security related problems while running Ethereal or at least to reduce the possible impact.
Line 15: Line 15:
'''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. Wether this is a problem for yourself will depend on the situation: A small !SoHo network will probably be less critical compared to a companies 24/7 mission critical web server.
Line 17: Line 17:
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. It's not the intention of this page to discuss the usage of Ethereal regarded by certain persons as being "insecure", because you can see network data like transported passwords. BTW: Security through obscurity just don't work.
Line 19: Line 19:
== Windows == = Why is Ethereal different? =
Line 21: Line 21:
The WinPcap (NPF) driver is loaded by Ethereal when it starts to capture live data. In most programs, 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 23: Line 23:
This loading requires administrator privileges. Once the driver is loaded, every local user can capture from it until it's stopped again. Ethereal 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 Ethereal code. Running "wc -l epan/dissectors/*.[ch]" returns about 1,000,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 25: Line 25:
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. Ethereal 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 Ethereal 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 Ethereal supports.
Line 27: Line 27:
So using Ethereal running in a user account could look like: To make things worse, the Ethereal development is done in an "experimental character" as new protocols are added all the time and existing ones are largely improved, the main reason that Ethereal has gained such a wide support of protocols. The developers providing code to Ethereal (literally hundreds) have very divergent programming experience, from advanced networking specialists to novice programmers, making it more likely that new bugs get in.
Line 29: Line 29:
Start the NPF driver: As a result, Ethereal is more vulnerable to attacks than most other programs.
Line 31: Line 31:
{{{runas /u:administrator "net start npf"}}} = Which user actions are critical? =
Line 33: Line 33:
Start Ethereal and work with it, including capturing, until the specific job is finished. The most critical action is reading packets (that's when they are first analyzed):
Line 35: Line 35:
Stop the NPF driver again:  * Open a capture file
 * While capturing, if "Update list of packets in real time" is used
 * After capture stops, if "Update list of packets in real time" is ''not'' used
Line 37: Line 39:
{{{net stop npf}}} = What can you do to protect yourself? =
Line 39: Line 41:
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. There are some things you can do:

 * Always update to the latest Ethereal version available as bugs are fixed often. You can join the announce mailing list to stay informed about new versions.
 * Don't run Ethereal 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 use a dedicated machine for this task.
 * Use a small capture tool which is less likely affected by security bugs, e.g.: tcpdump (upcoming: dumpcap) and transfer the capture file to the uncritical environment mentioned above

= Possible Developer Solutions =

There are many ways to improve Ethereal's security situation. Fortunately, none of them are mutually exclusive.

== Automatic Code Generation ==

It is possible (for some dissectors at least) to use a higher-level language to generate the C code for a dissector. If the translators have been reviewed to make sure they generate "safe" code, and the code they call has been reviewed to make sure it's safe, then dissectors written in those higher-level languages will be safe.

For example, some dissectors for protocols using ASN.1 are generated from an ASN.1 description of the protocol.

''Status:'' We're already doing this for many ASN.1-based protocols as well as NCP, DCE/RPC BUTC, and others. Most (possibly all) of Ethereal's dissectors could be autogenerated.

== Code Review ==

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 are doing the job of reviewing the patches before they are checked in the main source tree. This development model won't change for several reasons.

''Status:'' Independent researchers have done informal reviews in the past. Unfortunately no comprehensive review has been done to date.

== Privilege Separation ==

We can reduce the potential for harm by running Ethereal as a non-privileged user. This is difficult on some platforms, since "root" or "Administrator" privileges may be needed for capture. See ["CaptureSetup/CapturePrivileges"] for details.

''Status:'' Work on adding privilege separation is underway. See ["Development/PrivilegeSeparation"] for more details.

== API Improvements ==

Epan's tvbuff routines have gone a long way in preventing security holes in Ethereal's core. What happens after a dissector pulls data '''out''' of a tvbuff is another story, and is where most of our serious bugs come from. It should be possible to extend Ethereal's API to make it easier to handle data safely.

''Status:'' Unknown.

== Automated Testing ==

We have an [http://buildbot.ethereal.com automated build process] that runs tethereal against randpkt output, a capture file menagerie, and the menagerie after it's been fuzzed. Many bugs have been found using this process so far. More tests could be added, such as [http://valgrind.org/ Valgrind] and [http://www.gimpel.com/ Gimpel Lint].

It's also possible for developers to do fuzz/random testing themselves. Details can be found on the FuzzTesting page.

''Status:'' We need another buildslave, which probably won't happen until March at the earliest.

== Avoid problematic functions ==

We should avoid functions known to frequently cause security related problems, e.g. the ANSI-C function strcpy() will overwrite the destination area if the source string is too large for it.

''Status:'' Work in progress, details can be found in ["Development/SecureProgramming"].

Security

This page collects information about the secure usage of Ethereal.

TableOfContents

Overview

In the recent months, Ethereal 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 Ethereal 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 to attack Ethereal out there, this may change one day ...

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

Wether this is a problem for yourself will depend on the situation: A small SoHo network will probably be less critical compared to a companies 24/7 mission critical web server.

It's not the intention of this page to discuss the usage of Ethereal regarded by certain persons as being "insecure", because you can see network data like transported passwords. BTW: Security through obscurity just don't work.

Why is Ethereal different?

In most programs, 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.

Ethereal 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 Ethereal code. Running "wc -l epan/dissectors/*.[ch]" returns about 1,000,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.

Ethereal 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 Ethereal 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 Ethereal supports.

To make things worse, the Ethereal development is done in an "experimental character" as new protocols are added all the time and existing ones are largely improved, the main reason that Ethereal has gained such a wide support of protocols. The developers providing code to Ethereal (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, Ethereal is more vulnerable to attacks than most other programs.

Which user actions are critical?

The most critical action is reading packets (that's when they are first analyzed):

  • Open a capture file
  • While capturing, if "Update list of packets in real time" is used
  • After capture stops, if "Update list of packets in real time" is not used

What can you do to protect yourself?

There are some things you can do:

  • Always update to the latest Ethereal version available as bugs are fixed often. You can join the announce mailing list to stay informed about new versions.
  • Don't run Ethereal 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 use a dedicated machine for this task.
  • Use a small capture tool which is less likely affected by security bugs, e.g.: tcpdump (upcoming: dumpcap) and transfer the capture file to the uncritical environment mentioned above

Possible Developer Solutions

There are many ways to improve Ethereal's security situation. Fortunately, none of them are mutually exclusive.

Automatic Code Generation

It is possible (for some dissectors at least) to use a higher-level language to generate the C code for a dissector. If the translators have been reviewed to make sure they generate "safe" code, and the code they call has been reviewed to make sure it's safe, then dissectors written in those higher-level languages will be safe.

For example, some dissectors for protocols using ASN.1 are generated from an ASN.1 description of the protocol.

Status: We're already doing this for many ASN.1-based protocols as well as NCP, DCE/RPC BUTC, and others. Most (possibly all) of Ethereal's dissectors could be autogenerated.

Code Review

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 are doing the job of reviewing the patches before they are checked in the main source tree. This development model won't change for several reasons.

Status: Independent researchers have done informal reviews in the past. Unfortunately no comprehensive review has been done to date.

Privilege Separation

We can reduce the potential for harm by running Ethereal as a non-privileged user. This is difficult on some platforms, since "root" or "Administrator" privileges may be needed for capture. See ["CaptureSetup/CapturePrivileges"] for details.

Status: Work on adding privilege separation is underway. See ["Development/PrivilegeSeparation"] for more details.

API Improvements

Epan's tvbuff routines have gone a long way in preventing security holes in Ethereal's core. What happens after a dissector pulls data out of a tvbuff is another story, and is where most of our serious bugs come from. It should be possible to extend Ethereal's API to make it easier to handle data safely.

Status: Unknown.

Automated Testing

We have an [http://buildbot.ethereal.com automated build process] that runs tethereal against randpkt output, a capture file menagerie, and the menagerie after it's been fuzzed. Many bugs have been found using this process so far. More tests could be added, such as [http://valgrind.org/ Valgrind] and [http://www.gimpel.com/ Gimpel Lint].

It's also possible for developers to do fuzz/random testing themselves. Details can be found on the FuzzTesting page.

Status: We need another buildslave, which probably won't happen until March at the earliest.

Avoid problematic functions

We should avoid functions known to frequently cause security related problems, e.g. the ANSI-C function strcpy() will overwrite the destination area if the source string is too large for it.

Status: Work in progress, details can be found in ["Development/SecureProgramming"].

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