This page collects information about security topics using Ethereal.
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 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 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.
There are may 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.
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.
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.
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.
We have an [http://buildbot.ethereal.com automated build process] that runs tethereal against randpkt output and a capture file menagerie. Many bugs have been found using this process so far. More tests could be added, such as fuzz-testing capture data by corrupting random bits, or running tethereal under Valgrind.
Status: We need another buildslave, which probably won't happen until March at the earliest.