dont run a application as root.
this is not specific to ethereal, it applies to all software DONT run
apps as root!
if you log in as root it is game over already ethereal or no ethereal.
yes, ethereal contains bugs, so does all other software as well.
Bugs are fixed quickly when they are detected.
we do not intend to add bugs, they happen by accident. bad bugs are
usually fixed within 24 hours.
most of the time people want something that works reasonably well to
help them solve existing problems. not maybe have the feature added
9 months from now when some random person has audited the code.
ethereal developers do their best to avoid bugs. unfortunately bugs
do creap into the code.
thats life.
As for BSD, they made a decision that ethereal was not compatible with
their goals, good for them thats their decision.
> I think that this attitude is essentially what the OpenBSD people
> freaked about. -- no proactive code auditing, and possibly nobody
> on this list that knows how to do it properly (god know, that I
> don't but, if I'm lucky, I could learn fast).
since my time to play with ethereal is significantly limited, can i
send patches to you for auditing?
You are correct in the observation that no formla audit process exist
and there is no group to audit and approve patches. no such thing
exists.
BSD have specific goals with their distribution and ethereal can not
comply with these goals. It is the correct decision for BSD not to use
the ethereal application with their distribution. We do not have the
manpower to beome compatible with their goals. Deal with it, I do.
I even agree with their decision.
On Fri, 11 Feb 2005 03:35:29 -0800, Stephen Samuel <samuel@xxxxxxxxxxx> wrote:
> I'm cross-posting this to the ethereal-dev@xxxxxxxxxxxx
> and ports-bugs@xxxxxxxxxxx so that we can (hopefully) open a
> constructive dialog.
>
> Gilbert Ramirez wrote:
> ....
>
> > I can only think of two categories for Ethereal code... code with a
> > known security bug, and code with unknown security bugs. The Ethereal
> > community is very rapid in responding to security bugs; I don't know
> > of any instance where we left known security problems to linger.
> >
> > So, I don't see how we could categorize dissectors into security
> > levels. Either they are or they aren't, and if they aren't, we fix
> > them right away.
> .....
>
> That reads to me like "we can't be guaranteed to find all bogs,
> so why search for *any* of them. It's a rather defeatist approach.
>
> I think that this attitude is essentially what the OpenBSD people
> freaked about. -- no proactive code auditing, and possibly nobody
> on this list that knows how to do it properly (god know, that I
> don't but, if I'm lucky, I could learn fast).
>
> The OpenBSD group doesn't expect perfection (although they would
> like a relatively close approximation in the base code). They do,
> however look for a proactive approach to weed out systematic
> problems. From my read of things, it seems like the source of their
> upset is that they saw a pattern of bugs showing up in ethereal,
> over a relatively short period of time, but no apparent attempt
> to resolve that pattern.
>
> At the heart of the problem is that Ethereal deals with network
> code -- often unknown or even hostile code. This means that any
> dissector bug which (theoretically) allows for arbitrary code execution
> becomes a Remote Exploit -- and given that it's often a root user
> doing the work, it can quickly escalate into a Remote Root Exploit
> (which they consider a worst-case situation).
>
> From a general feeling of things, It seems like a lot of the exploits
> that show up in ethereal are of a similar type (Buffer overflows, etc.
> because the dissector writer designed for the standard case, but didn't
> build it to survive worst case or actively hostile packets). A lot of
> that is stuff that could easily be caught with a code audit -- but a
> code audit is WORK.
>
> Once code auditing work is relatively well entrenched in this group
> then we can separate code into two more useful groups -- code that
> has been audited and code that hasn't been.Code that has been audited
> would be considered 'default-safe'. Code that hasn't been audited
> would be explicit-load-only. That way people would be a bit more sure
> that a default install of ethereal is relatively unlikely to contain
> exploitable bugs.
>
> --
> Stephen Samuel +1(604)876-0426 samuel@xxxxxxxxxxx
> http://www.bcgreen.com/~samuel/
> Powerful committed communication. Transformation touching
> the jewel within each person and bringing it to light.
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>
