["Anders Broman (AL/EAB)" <anders.broman@xxxxxxxxxxxx>]

Hi,
I would also think the usage of Ethereal differs quite a lot and therfore the focus of developers may differ
for me the abillity of Ethereal to dissect packets is far more interesting than the security issue as
I only do sniffing in private networks, of cource I'd like to write secure and bugfree code but to have a
reasonable OK dissector to be able to do my 'real' work is far more important to me.

This is one of the reasons why I like the Ethereal development model as new and intersting protocols and features gets added quickly.
Best regards
Anders Broman

-----Original Message-----
From: ethereal-dev-bounces@xxxxxxxxxxxx
[mailto:ethereal-dev-bounces@xxxxxxxxxxxx]On Behalf Of Gilbert Ramirez
Sent: den 11 februari 2005 15:09
To: Stephen Samuel
Cc: ports-bugs@xxxxxxxxxxx; Ethereal development
Subject: Re: Disector categories (Re: [Ethereal-dev] Priv sep in
ethereal)


No, not defeatist, just realist, considering the current method of
Ethereal development. But when I wrote that I didn't realize that the
suggestion was a formal code auditing procedure. I agree; with that in
effect, the categories would be "audited" and "not-yet-audited", which
is more useful.

--gilbert


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