Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Ethereal-dev: Re: [Ethereal-dev] Harsh criticism from the OpenBSD folks

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <gharris@xxxxxxxxx>
Date: Mon, 23 Aug 2004 01:34:55 -0700
(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.)