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 9 and 12 (spanning 3 versions)
Revision 9 as of 2005-05-12 20:37:54
Size: 3921
Editor: GeraldCombs
Comment: Update automated testing info
Revision 12 as of 2006-01-22 14:58:29
Size: 5445
Editor: UlfLamping
Comment: fix link
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
This page collects information about security topics using Ethereal. This page collects information about the secure usage of Ethereal.
Line 7: Line 7:
= Overview = = Introduction =

In the recent months (years?), 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 out there to attack Ethereal, 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? =
Line 11: Line 23:
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 700,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. As a result, Ethereal is more vulnerable to attacks than most other programs. 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 15: Line 27:
= Possible Solutions = 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 17: Line 29:
There are may ways to improve Ethereal's security situation. Fortunately, none of them are mutually exclusive. As a result, Ethereal is more vulnerable to attacks than most other programs.
Line 19: Line 31:
== Automatic Code Generation == = Which actions are critical? =
Line 21: Line 33:
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. Having a bug in the GUI code can be quite annoying, e.g. a crash while printing a capture file. However, these bugs are usually not security related as they cannot be triggered from the outside.
Line 23: Line 35:
For example, some dissectors for protocols using ASN.1 are generated from an ASN.1 description of the protocol. 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 25: Line 37:
''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.  * 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 27: Line 41:
== Code Review == = Administrator/root account usually not required! =
Line 29: Line 43:
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. Many Ethereal users think that Ethereal requires a Administrator/root account to work with.
Line 31: Line 45:
''Status:'' Independent researchers have done informal reviews in the past. Unfortunately no comprehensive review has been done to date. 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 33: Line 47:
== Privilege Separation == First of all, most Ethereal functions can always be used with a (probably very limited) user account. Especially the protocol dissectors which are showing most of the security related bugs doesn't need a root account!
Line 35: Line 49:
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. 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.
Line 37: Line 51:
''Status:'' Work on adding privilege separation is underway. See ["Development/PrivilegeSeparation"] for more details. = Protect Yourself! =
Line 39: Line 53:
== API Improvements == There are some things you can do:
Line 41: Line 55:
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.  * 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 even 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
Line 43: Line 60:
''Status:'' Unknown. = Help is on the way! =
Line 45: Line 62:
== Automated Testing == The Ethereal developers agree that the current situation isn't actually satisfying.
Line 47: Line 64:
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]. Current effort is spend in several ways to improve Ethereal in that regard:
Line 49: Line 66:
It's also possible for developers to do fuzz/random testing themselves. Details can be found on the FuzzTesting page.  * Automated tests uncovers previously unknown bugs
 * code reviews take place
 * potential unsecure functions are removed from the code
 * privilege seperation is being implemented (running the capture code in it's own task)
 * ... and many other things
Line 51: Line 72:
''Status:'' We need another buildslave, which probably won't happen until March at the earliest. 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 Ethereal.

TableOfContents

Introduction

In the recent months (years?), 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 out there to attack Ethereal, 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 actions are critical?

Having a bug in the GUI code can be quite annoying, e.g. a crash while printing a capture file. 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 usually not required!

Many Ethereal users think that Ethereal requires a Administrator/root 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 Ethereal functions can always be used with a (probably very limited) user account. Especially the protocol dissectors which are showing most of the security related bugs doesn't 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 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 even 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

Help is on the way!

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

Current effort is spend in several ways to improve Ethereal in that regard:

  • Automated tests uncovers previously unknown bugs
  • code reviews take place
  • potential unsecure functions are removed from the code
  • privilege seperation is being implemented (running the capture code in it's own task)
  • ... 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)