But, as Guy already pointed out, on BSD systems you do
not need root privileges, only read access to /dev/bpf?
Isn't that acceptable for the OpenBSD developers?
Best regards
Michael
On Aug 24, 2004, at 4:53 PM, Giles Scott wrote:
Rather than speculating, perhaps we should talk to the OpenBSD people
about what their concerns are. I am a bit dismayed that they chose to
pull Ethereal out of their distribution without making any effort to
voice their concerns to us.
From OpenBSD mailing list
http://lists.openbsd.org/cgi-bin/mj_wwwusr?
user=&passw=&list=ports&brief
=on&func=archive-get-part&extra=200407/209
"
From Marc Espie <espie@xxxxxxxxx>
Subject Re: Replacement for Ethereal
Date Wed, 21 Jul 2004 00:47:47 +0200
[Part 1 text/plain us-ascii (1.0 kilobytes)] (View Text in a separate
window)
Just to cut this huge discussion short, the main problem with
ethereal is that it needs to grab raw packets.
And under Unix, to grab raw packets, you must be root.
which is a big, big, problem with respect to security.
If you look closely at OpenBSD, you'll notice there are other
ugly beasts that need special privileges to do special things.
The X Windows server, for instance.
And guess what ? Most of these ugly beasts run as two processes now,
of which just one them runs as root. That's called privilege
separation,
and that's about the simplest redesign that could solve ethereal.
so that the process that gets raw packets just gets raw packets, and
passes them on to the process that does the actual work.
That way, you get a much smaller chunk of code to fix. And breakage
in the packet analyzer will be much less serious.
BTW, these days, any new packet analyzer that pretends to replace
ethereal and doesn't use privilege separation is a complete joke.
"
-----Original Message-----
From: ethereal-dev-bounces@xxxxxxxxxxxx
[mailto:ethereal-dev-bounces@xxxxxxxxxxxx] On Behalf Of Joerg Mayer
Sent: Tuesday, August 24, 2004 7:12 AM
To: Ethereal development
Subject: Re: [Ethereal-dev] Harsh criticism from the OpenBSD folks
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".
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
2) implement d)
3) Implement b)
4) In case we are still unhappy, think about d)
ciao
Joerg
--
Joerg Mayer
<jmayer@xxxxxxxxx>
We are stuck with technology when what we really want is just stuff
that
works. Some say that should read Microsoft instead of technology.
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev
