Ethereal and security

The original comment was unnecessary, however, and apologies are offered. In an attempt to make amends, your editor decided to take a closer look at Ethereal and its approach to security. What much of the world sees is a long list of security advisories and little else; if there is a larger story, it has not been told outside of the developers' lists. As it turns out, there is, indeed, a larger story.

The list of Ethereal security advisories is indeed long. The six advisories issued in 2005 enumerate 105 different security-related bugs, a number of which are of the form "several dissectors will do something unpleasant in these circumstances." There are 23 different CVE numbers cited. The Ethereal security page gives a number of suggestions for running Ethereal in a more secure way (don't run as root, use something like tcpdump to capture packets, etc.), and notes that "The Ethereal developers agree that the current situation isn't actually satisfying." Your editor, it seems, is not entirely alone in noting that some security issues may exist with Ethereal.

Ethereal has a couple of special challenges. One is that it must deal directly with arbitrary data which may have been specially generated by hostile parties. Any set of bits can come off a network, and Ethereal must do the right thing with it; most applications, instead, receive a cleaner and more controlled input stream from the outside. Ethereal also must deal with a wide variety of packet types, which leads to the inclusion of a large library of protocol-specific "dissectors." These dissectors bear some resemblance to device drivers in an operating system kernel: they are specialized, written by a diverse group of authors, and can be hard for others to review and test. And, as with drivers in the kernel, dissectors are the source of a large percentage of Ethereal bugs.

Ethereal vulnerabilities can also be serious. While problems in packages like cube, zoo, or tetex are very much worth fixing, the chances of systems being compromised by those vulnerabilities are relatively small. Ethereal, however, is a tool used by system and network administrators. Known vulnerabilities in Ethereal can be used to compromise an administrator's system; all that is required is the injection of a suitably-crafted packet onto a network where Ethereal is running. So Ethereal vulnerabilities could be especially attractive to an attacker with a specific target. This fact can be driven home by doing a quick search for Ethereal exploits; a number have been posted over the years.

So the Ethereal developers clearly need to keep security in mind. The good news is that they seem to be doing exactly that. While some of the vulnerabilities disclosed in 2005 were found by outside parties, the vast majority of them were turned up by the Ethereal hackers themselves. The developers, it seems, are putting some significant effort into finding problems before hostile outsiders do. This activity nicely explains both the large number of advisories and the small number of defects in the current Ethereal code base.

Clearly, the right kind of work is being done. Here (from the Ethereal security development page) are some of the things the Ethereal developers are doing to improve the security of their project:

• Fuzz testing. As has been discovered in many applications, the feeding of random data to a program can turn up all kinds of interesting behavior. Ethereal has a "randpkt" utility which feeds entirely random data to the system. There is also an "editcap" program which introduces random corruption into files containing streams of real packets. Any dissector which is not truly paranoid about the data contained in the packets presented to it will eventually be caught out by a fuzzed packet.

• Automatic code generation. Rather than hand-crafting code to deal with the structure of every packet type, the project is looking at generating dissector code from a description of the packet format. Once the code generator has been verified as safe, the resulting dissectors should be much more solid. Code generation is being used in a number of projects (Samba 4, for example) to produce better code in less time; Ethereal is machine generating some of its dissectors now, with an eye toward generating most or all of them at some point in the future.

• Various changes aimed at avoiding dangerous code. These include core API changes to make certain kinds of errors harder to create. The tvbuff abstraction, for example, allows a portion of a packet to be passed to a dissector and catches any attempts to access data outside of that area. The Ethereal developers are also making a (somewhat belated) effort to stop using dangerous C library functions like sprintf() and strcat().

Throw in techniques like privilege separation and good, old-fashioned code review, and the result should be a relatively secure package. Perfect security is hard to come by, and Ethereal users should still stay on top of their updates. But the Ethereal developers appear to have a handle on the problem and are trying to do the right things. If all free software projects took security as seriously, our systems would be rather more solid.