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.
