(No subject? Did I clear it accidentally? Here's a copy, hopefully
*with* a subjct line.)
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.)
