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 6 and 7
Revision 6 as of 2005-02-11 02:10:32
Size: 5844
Editor: UlfLamping
Comment: minor changes
Revision 7 as of 2005-02-20 16:55:37
Size: 7237
Editor: GeraldCombs
Comment: Add a few more methods to improve security.
Deletions are marked like this. Additions are marked like this.
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 developers 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" (whether it's from a live capture or loaded from a file), so a code review on the relevant parts would be a code review of most if not all of the complete Ethereal code which would be a '''huge''' effort, and not all problems might be found after all. This makes Ethereal more vulnerable to attacks than most other programs. 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 11: Line 11:
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, and another reason is that implementations of other languages might not be as commonly available on all the platforms Ethereal support. Some of this might be solved, at least for some dissectors, by having higher-level languages used to describe protocols, with translators to C for those languages; 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. 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.
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 are doing the job of reviewing the patches before they are checked in the main source tree. 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 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. = Possible Solutions =
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; see below. 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.

== 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 "Platform-Specific Information" below 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 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.


= Platform-Specific Information =
Line 52: Line 88:
















Security

This page collects information about security topics using Ethereal.

TableOfContents

Overview

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.

Possible Solutions

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.

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 "Platform-Specific Information" below 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 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.

Platform-Specific Information

BSD (including Mac OS X)

In order to capture packets, you must have read access to the BPF devices in /dev/bpf*.

On BSDs without a devfs, the special files for those devices are on your root file system, and changes to them will persist across reboots. In order to allow yourself, or yourself and others, to capture traffic without running Ethereal as root, either make them owned by you, or make them owned by a group to which you and others to whom you want to give capture permission belong and give that group read access, or, if your BSD supports ACLs on special files, add the users who should have permission to capture to the ACL, with the ACL entry giving them read permission. You will probably need super-user permission to do this.

On BSDs with a devfs (this includes Mac OS X), this might involve more than just having somebody with super-user access setting the ownership and/or permissions on the BPF devices - it might involve configuring devfs to set the ownership or permissions every time the system is booted, if the system supports that; FreeBSD 5.x's devfs does. If the system doesn't support that - Mac OS X's devfs doesn't, you might have to find some other way to make that happen at boot time, such as a command in one of the system rc files, or a startup item in OS X; see the ChmodBPF directory in the current CVS version of libpcap for such a startup item.

Digital/Tru64 UNIX

Any user can, in principle, capture network traffic. However, no user (not even the super-user) can capture in promiscuous mode on an interface unless the super-user has enabled promiscuous-mode peration on that interface using pfconfig(8), and no user (not even the super-user) can capture unicast traffic received by or sent by the machine on an interface unless the super-user has enabled copy-all-mode operation on that interface using pfconfig, so useful packet capture on an interface probably requires that either promiscuous-mode or copy-all-mode operation, or both modes of operation, be enabled on that interface. You might be able to limit the set of users allowed to capture traffic by changing the ownership and/or permissions of the /dev/pfilt* devices.

Windows

The WinPcap (NPF) driver is loaded by Ethereal when it starts to capture live data.

This loading requires administrator privileges. Once the driver is loaded, every local user can capture from it until it's stopped again.

To be secure (at least in a way), it is recommended that even an administrator should always running in a user account, and only start processes that really need the administrator privileges.

So using Ethereal running in a user account could look like:

Start the NPF driver:

runas /u:administrator "net start npf"

Start Ethereal and work with it, including capturing, until the specific job is finished.

Stop the NPF driver again:

runas /u:administrator "net stop npf"

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; see [http://winpcap.polito.it/misc/faq.htm#Q-7 this note in the WinPcap FAQ].

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