Ethereal-dev: Re: [Ethereal-dev] PROTOS traces

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: Tue, 5 Mar 2002 02:34:18 -0800
On Thu, Feb 28, 2002 at 07:04:26PM -0800, Guy Harris wrote:
> ...and the resulting Ethereal (and Tethereal) appear to be able to
> process the capture with no problems.  Give it a try on your machine.

I've checked in a change to "asn1.c" for another problem that the PROTOS
captures found.

The bad news is that the other captures appear to be overflowing a
fixed-size buffer internal to the UCD SNMP library.

The good news is that UCD SNMP 4.2.2 introduced (but didn't document in
the man pages) APIs that looks as if they support formatting object IDs
and variables into a dynamically-growing buffer, rather than into a
fixed buffer, so that if we require UCD SNMP 4.2.2 or later, we can
probably fix that particular problem.

CMU SNMP doesn't use an internal buffer in one of the offending
routines; however

	1) it uses it in some other routines

and

	2) it still doesn't have an API to let you format into a
	   dynamically-growing buffer or into a buffer with a length (so
	   that it won't run past the end of the buffer)

so we'd probably still be vulnerable to buffer overflows if we used it.

Requiring UCD SNMP 4.2.2 or later - or, to be more specific, requiring
the "format into a dynamically-growing buffer" routines - would:

	1) allow us to get rid of the CMU SNMP support stuff (by
	   removing support for CMU SNMP);

	2) allow us to get rid of the workaround for the UCD SNMP 4.1.1
	   binary incompatibility with earlier UCD SNMP releases (as we
	   won't support those earlier releases);

	3) allow us to get rid of the workaround for the ill-advised
	   change of the UCD SNMP API in some Linux distributions
	   (because we wouldn't use the offending routines - we'd be
	   using the dynamic-buffer versions of those routines);

and *might* also, by forcing the RPMs of Ethereal to be built with a
later version of the SNMP library, clean up some of the installation
problems with those RPMs (assuming that the problem is that the RPM
binaries are linked with, and depend on, older versions, and that the
RPM and/or shared-library dependencies of the newer versions are
different).