Coverity releases first defect survey results [LWN.net]

Coverity releases first defect survey results

Posted Mar 6, 2006 21:15 UTC (Mon) by jwb (subscriber, #15467)
In reply to: Coverity releases first defect survey results by jmayer
Parent article: Coverity releases first defect survey results

Hrmm, just looking at the Ethereal notices posted by this site:

A stack-based buffer overflow was discovered in the OSPF dissector... ethereal denial of service in IRC dissector...

- the ISAKMP dissector could exhaust system memory
- the FC-FCS dissector could exhaust system memory
- the RSVP dissector could exhaust system memory
- the ISIS LSP dissector could exhaust system memory
- the IrDA dissector could crash
- the SLIMP3 dissector could overflow a buffer
- the BER dissector was susceptible to an infinite loop
- the SCSI dissector could dereference a null pointer and crash
- the sFlow dissector could dereference a null pointer and crash
- the RTnet dissector could dereference a null pointer and crash
- the SigComp UDVM could go into an infinite loop or crash
- the X11 dissector could attempt to divide by zero
- if SMB transaction payload reassembly is enabled the SMB dissector
could crash (by default this is disabled)
- if the "Dissect unknown RPC program numbers" option was enabled, the
ONC RPC dissector might be able to exhaust system memory (by default
this is disabled)
- the AgentX dissector could overflow a buffer
- the WSP dissector could free an invalid pointer
- iDEFENSE discovered a buffer overflow in the SRVLOC dissector

The iSNS dissector... The SMB SID snooping capability in ethereal ... The SNMP dissector in ethereal ... certain SIP messages ... The AIM dissector ... The SPNEGO dissector ... Buffer overflow in the MMSE dissector ... a problem in DICOM dissection ... An invalid RTP timestamp ... The HTTP dissector ... improperly formatted SMB packet ...

As far as I can tell, every vulnerability in Ethereal has been in the dissectors. Perhaps I should not be using the terms "plug-in" and "dissector" interchangably, but clearly the dissectors are the problem. And you can fairly easily find all the future Ethereal vulnerabilities by grepping the dissector source directory for "char buf[256];".

I've always felt that the only good way to run Ethereal would be to operate the dissectors in a separate, non-privileged process. So far Ethereal has resisted privilege separation, even though the topic has been broached on the mailing list numerous times. Perhaps in the future they will implement this.

The only safe way to run Ethereal today is to recompile it with almost all the protocols disabled, capture the packet stream using tcpdump or another utility, chown the dump file to a non-user, then run Ethereal against the dump file in the non-users account. Any other use of Ethereal, especially against live data off the wire, is extremely hazardous.

(Log in to post comments)

Coverity releases first defect survey results

Posted Mar 7, 2006 21:10 UTC (Tue) by azhrei_fje (guest, #26148) [Link]

The only safe way to run Ethereal today is to recompile it with almost all the protocols disabled, capture the packet stream using tcpdump or another utility, chown the dump file to a non-user, then run Ethereal against the dump file in the non-users account. Any other use of Ethereal, especially against live data off the wire, is extremely hazardous.

Unless I'm missing something, that seems a bit excessive. Why not create a named pipe and tell ethereal to read the pipe as the dump, then run tcpdump and tell it to write its data to the same pipe?

I must be missing some aspect of this (perhaps issues with reading/writing data from/to pipes?), but it seems pretty straight-forward. I suppose it could be that ethereal might want to seek on the input (?), but I can't see why it would...

Coverity releases first defect survey results

Posted Mar 9, 2006 10:06 UTC (Thu) by jmayer (subscriber, #595) [Link]

We are in the process of doing something like that: The current cvs HEAD
has a utility called dumpcap, which does the capturing and ethereal uses
it instead of capturing directly. We still need to change tethereal to do
the same. So today ethereal (and tethereal hopefully soon) can be run
without root privileges. This of course is not an issue on Windows or
BSD, where this can be achieved by other means today. Still, it will
noticably speed up the capture start on those systems too.
Note that this only addresses part of the problem, as faulty dissectors
will still allow malicious traffic coded for faulty dissectors to take
over the user running ethereal. But at least it will not present
immedeate root access any more.