We can currently keep global and per-user lists of disabled protocols.
Could we use that as a basis for {en|dis}abling protocols according to
their level of trust?
Also, would it be helpful to have Ethereal fetch a list of known bad
dissectors via the web at startup and give the user the option of
disabling them, similar to the security check Firefox performs at startup?
Gilbert Ramirez wrote:
> 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
