| |||||||||||||
|
| |||||||||||||
Coverity releases first defect survey resultsCoverity releases first defect survey resultsPosted Mar 6, 2006 19:11 UTC (Mon) by jwb (guest, #15467)Parent article: Coverity releases first defect survey results
Ethereal's vulnerabilities are almost always in plug-in code modules. Some random person will contribute a dissector for, say, the protocol used by AIM. The bugs nearly all take the form of unprotected string copies into arrays of type char, either using a length that should be considered untrusted, or by null-termination.
Maybe the Coverity checker didn't look at the plug-ins.
(Log in to post comments)
Coverity releases first defect survey results Posted Mar 6, 2006 20:54 UTC (Mon) by jmayer (subscriber, #595) [Link] Ethereal has a very small number of plugins, and most bugs are *NOT* inthe plugins. Your information is wrong here.
Coverity releases first defect survey results Posted Mar 6, 2006 21:15 UTC (Mon) by jwb (guest, #15467) [Link] 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 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.
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 HEADhas 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.
|
|
||||||||||||