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.
>
>
