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.
