[Guy Harris <gharris@xxxxxxxxx>]

Gerald Combs wrote:

> http://www.openbsd.org/cgi-bin/cvsweb/ports/net/ethereal/Attic/Makefile?hideattic=0
>
> "Remove ethereal from the ports tree.  Right during 3.5, it had more
>  than a dozen remote holes being fixed, that we shipped with.  Weeks
>  later things have not improved, and there continue to be problems
>  reported to bugtraq,

Hmm.  If by "bugtraq" they mean the BUGTRAQ mailing list, the last 
message I can find in the SecurityFocus archives mentioning Ethereal in 
the subject line was on July 23, talking about problems in 0.10.4.

>  and respective band-aids

So what distinguishes a "band-aid" from a fix considered more acceptable?

>  Maybe someone will at least privilege separate this one day,

I'm not sure what privilege separation means, but if it means not 
running code doing packet capture as root, you can do *that* on any OS 
with "BSD" in its name, and even one with "Mac OS X" in its name:

	$ ls -l /dev/bpf*
	crw-------  1 gharris  wheel   23,   0 23 Aug 01:02 /dev/bpf0
	crw-------  1 gharris  wheel   23,   1 22 Aug 23:29 /dev/bpf1
	crw-------  1 gharris  wheel   23,   2 22 Aug 23:29 /dev/bpf2
	crw-------  1 gharris  wheel   23,   3 22 Aug 23:29 /dev/bpf3

For OSes less helpful than that, privilege separation (e.g., having the 
capture done by a small, simple program that communicates with the GUI 
program over a pipe) would still be a good idea.

But all privilege separation does is arranges that buggy code run as you 
rather than as root.  That's useful, but preventing buggy code would be 
useful as well.

I'd have to look at our advisories in detail, but:

enpa-sa-00015 has:

	CAN-2004-0633, which is probably *not* the one fixed by revision 11013, 
as I'm not sure why that'd cause a crash rather than just a misdisplayed 
packet;

	CAN-2004-0634, which is probably the result of some code not checking 
for a null pointer;

	CAN-2004-0635, which was presumably fixed in revision 11260, and was 
the result of not checking for an error.

enpa-sa-00014 has:

	a SIP bug, the cause of which I'm not sure of;

	an assertion failure in the AIM dissector;

	a null-pointer dereference in the SPNEGO dissector;

	a buffer overflow in the MMSE dissector.

I don't know how many of them are buffer overflows (which are, I 
suspect, the ones most likely to cause serious security holes of the 
"running arbitrary code" type rather than causing just denial-of-service 
crashes) or, of those, how many are due to reading into fixed-length 
buffers that really should be dynamically-allocated buffers (often 
thanks to C string support being feeble and Ethereal not using GLib 
dynamic string support or rolling its own dynamic string support.

I also don't know how many have been due to reading strings into 
fixed-length buffers where that's reasonable, but failing to 
null-terminate the strings.

I suspect that at least *some* of the problems might have been avoided 
with a higher-level language in which to write dissectors, with a 
translator that takes that language and generates C code that avoids 
using unsafe idioms.  Given that we have a lot of dissector 
contributions, and not a lot of time to review them, that might at least 
help.  (If the language is powerful enough, the translator might also be 
able to generate code that properly checks for null pointers in at least 
some cases.)

(At least tvbuffs let us more easily avoid some of the problems tcpdump 
has had with overflowing the *packet* buffer.)