Wireshark · Ethereal-dev: RE: [Ethereal-dev] Pesky PROTOS packet

["HOOD, Andy" <ahood@xxxxxxxxxxxxxx>]

Solaris 2.6 Sparc
~: ethereal -v
ethereal 0.9.1, with GTK+ 1.2.8, with GLib 1.2.8, with libpcap 0.5, with
libz 1.1.3, with UCD SNMP 4.2.3

Core was generated by `ethereal'.
Program terminated with signal 10, Bus Error.

#0  0xef7346b0 in sprint_objid (
    buf=0x2e313135 <Address 0x2e313135 out of bounds>, objid=0x2e33372e, 
    objidlen=825308462) at mib.c:2869


-----Original Message-----
From:	Guy Harris [mailto:gharris@xxxxxxxxx]
Sent:	Wednesday, 27 February 2002 15:05
To:	Gilbert Ramirez
Cc:	Gerald Combs; ethereal-dev@xxxxxxxxxxxx
Subject:	Re: [Ethereal-dev] Pesky PROTOS packet

On Tue, Feb 26, 2002 at 09:38:15PM -0600, Gilbert Ramirez wrote:
> It crashes on my Debian linux system, also NET SNMP 4.2.3. It fails
> in read_objid in the snmp library, which is called from sprint_obj(),
> which we call in packet-snmp.c

It crashes on my system (FreeBSD 3.4/x86); "_get_symbol()" trashes the
stack.  "_get_symbol()" is called from "_sprint_objid()", called from
"sprint_objid()".

The OID length is 802; the string buffer into which it's formatting the
OID is MAX_STRING_LEN, i.e. 2048, characters long.

If, on average, a component of the OID takes more than 2.55 or so
characters, that's going to overflow the buffer.

Unfortunately, "sprint_objid()" takes, as arguments:

	a pointer to the string buffer into which to format the OID;

	an OID pointer;

	an OID len;

but no buffer length, so it'd either have to have a hard-wired maximum
string size, or do no bounds checking.

The latter appears to be the case, even in 4.2.3.

> According to the NET SNMP website, version 4.2.3 is not supposed to
> contain the vulnerability bug.

There's more than one vulnerability.  The ASN.1 parsing vulnerabilities
are, I think, fixed in 4.2.3 (a quick comparison of 4.2.2 with 4.2.3
shows some checks for bogus lengths added in 4.2.3); however, we don't
use the SNMP library's ASN.1 parsing, so we don't have that library's
bugs (instead, we have our own bugs, but that particular bug should be
fixed int the current CVS code).

However, there are also buffer-overflow vulnerabilities in the
formatting code; we *do* use the formatting code, and 4.2.3 doesn't
appear to fix them.

The problem is that you'd need an API change to fix them (think
"sprintf" -> "snprintf").  That's what the "helpful" fix in some
versions of Red Hat does; unfortunately, the way it changes the API is
to change the calling sequence of routines *without* changing their
names, which breaks both source and binary compatibility.

You could, I guess, argue that breaking source compatibility isn't a
problem, as you could argue that nobody should be using the unsafe
formatting APIs, and it's therefore OK if code written to the old APIs
fails to compile.

Breaking binary compatibility, though, should be done by introducing
*new* APIs with the new calling sequences, so that executable images
expecting the old API don't just call the formatting routines with the
wrong calling sequence and die some weird death.  Either

	1) the old APIs should be kept around, for backwards
	   compatibility

or

	2) the old APIs should be removed, so that programs using the
	   old API fail with a run-time linker error when using the
	   shared library

or

	3) both should be done, with the old-API library keeping its
	   current version number and the new-API library getting a new
	   version number, so applications linked with the old shared
	   library don't bind to the new one.

_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev

	-------------------------------------------------------
NOTE:	  The attachment below was deleted because it had a
	  suspicious file name (winmail.dat).

	  It is the policy of this list to drop any message
	  attachments that may be executable.  See
	  http://www.ethereal.com/lists/#lists
	  for more details.
	-------------------------------------------------------

This message has been 'sanitized'.  This means that potentially
dangerous content has been rewritten or removed.  The following
log describes which actions were taken.

Sanitizer (start="1014784760"):
  Part (pos="1747"):
    SanitizeFile (filename="unnamed.txt", mimetype="text/plain"):
      Match (rule="2"):
        Enforced policy: accept

  Part (pos="5452"):
    SanitizeFile (filename="winmail.dat", mimetype="application/ms-tnef"):
      Match (rule="1"):
        Enforced policy: drop

      Replaced mime type with: text/plain
      Replaced file name with: MANGLED_ON_PURPOSE-244.txt

  Total modifications so far: 1


Anomy 0.0.0 : Sanitizer.pm
$Id: Sanitizer.pm,v 1.32 2001/10/11 19:27:15 bre Exp $