ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
July 17th, 2024 | 10:00am-11:55am SGT (UTC+8) | Online

Ethereal-dev: Re: [Ethereal-dev] Harsh criticism from the OpenBSD folks

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Jeff Morriss <jeff.morriss@xxxxxxxxxxx>
Date: Tue, 24 Aug 2004 15:31:14 -0400


Joerg Mayer wrote:

On Mon, Aug 23, 2004 at 11:06:08PM -0500, Gerald Combs wrote:

So what distinguishes a "band-aid" from a fix considered more acceptable?


IMNSHO, privsep is a band-aid in the Ethereal case:
The problem of obtaining root privs goes away, yes, but the malicious code
is then executed as the user, which is not much better. The problem is also
there if a user runs "ethereal -r file-with-bad-packet.pcap".

I am by no means a security expert but it seems to me that a local-access exploit is _much_ better than a local-root-access exploit...

We have a few options here:
a) Do privsep where relevant (e.g. on systems that require root perms to
  capture data).
b) Identify which type of errors allow exploits, which coding errors led
  to them and do a code audit as well as provide some infrastructure in
  order to prevent them in the future (like tvbuff).
c) Work with generators and migrate all dissectors to some specification
  language.
d) Provide dissectors with a flag that gives a default state (enabled/
  disabled) in case the config file doesn't have anything different to
  say. Disable most dissectors by default and review those that are
  enabled by default.

I don't think that a) achieves much as far as security is concerned. The
"proper" solution would be to simply do not call any dissectors when run
as root - it's easier to implement and doesn't suffer the side effects -
and while
c) may be a long term solution, I don't think it will be in place for quite
a while and after that it will take years to migrate all existing dissectors.
d) is a solution that is easy to implement and which is quite effective as
far as security is concerned.
c) should also be quite doable.

So, in case we really care about the situation (which we should), I'd
suggest to start with 1) disable dissection when run as root

My $.02:

I very frequently run Ethereal as 'root' (because I need to capture things) but often do it in a hurry to check something out. Or, I need to do it and "update in real time" while I wait for a particular message to show up or problem to occur or whatever...

If dissection wasn't done then in the first case I'd have more work to do (violin please!) and in the 2nd case I'd never know when I hit the case I was interested in. :-(

Also, I tend to capture just on "controlled" networks where there is very little on the wire besides what I'm interested in.


I must admit that I like the privsep idea because what I really want to do is install Ethereal setuid-root so I don't have to:

% su
# ethereal
X11 connection rejected because of wrong authentication.
Gdk-ERROR **: X connection to aspen:10.0 broken (explicit kill or server shutdown).
# # Argh: 'ssh' doesn't think 'root' should be able to run X apps through my connection...
# exit
% su -
# export DISPLAY=mylaptop:0.0
# ethereal

but of course GTK won't premit that:

Gtk-WARNING **: This process is currently running setuid or setgid.
This is not a supported use of GTK+. You must create a helper
program instead. For further details, see:

    http://www.gtk.org/setuid.html

Refusing to initialize GTK+.