Re: SNMP Vulnerability Hype

From: Valdis Kletnieks (valdis.kletnieks@vt.edu)
Date: 02/22/02 

From: Valdis Kletnieks <valdis.kletnieks@vt.edu>
Date: 22 Feb 2002 11:45:14 -0500

Michael Soukup <msoukup@alumni.utexas.net> writes:

> People who don't have to solve the problems should not be so quick to
> criticize or condemn.

I wasn't critizicing or condemning. I've had to "solve the problem"
myself on a number of occasions (I'm still not sure if I should take
the credit for finding an AIX linker bug in Sendmail 8.10.0 like 18
hours (literally) after the release, or the blame for not spotting it
during the beta cycle. All in all, probably a Good Thing - if I'd
spotted it during the beta cycle, I'd probably not have pointed out to
IBM that some of their products had the same issue...)

> My understanding is that IBM began finding and fixing problems in SNMP
> going back to at least a few years ago. I doubt every single possible
> security exposure has been found,

Exactly my point (see below).

> but enough have been found for AIX,
> when patches (APARs as these fixes are called by IBM) are applied on a

I've been doing AIX for a living since we were an ESP site for
AIX/370, and I spent a number of years doing VS/1 and HASP hacking for
a previous employer before that - I'm painfully familiar with APARs,
as I've opened at least 400 or so of them myself (many during the
AIX/370 test - I'd like to apologize to the IBM Austin crew who had to
deal with the week I filed 15 legitimate Sev-1s ;)

> frequent basis (as all good sys admins are supposed to be doing for the
> systems under their care), that AIX passed the Oulu University PROTOS
> test suite, which is what the CERT Advisory was about. The statement by
> IBM, as regards the Advisory, is likely about as honest as it could be.

My point was that you need to be careful to remember that "passing
the PROTOS test suite" is *NOT* the same thing as "we've closed the holes".
There's a *lot* of ugly corner cases in there, and I'm willing to bet
there's still bugs that weren't tested by PROTOS, just waiting to be
found...

Also, IBM stated "we fixed bugs last year" and did *NOT* come out
and say "these bugs addressed the current vulnerability". And we've
seen a number of vendors say "not believed to be vulnerable" and later
on had to release a patch for a modification of the original exploit...

Now, I may have missed an APAR announcement somewhere along the line, but
a quick 'grep -i snmp' and tossing out all the HACMP and SP-only stuff
finds these likely candidates:

APAR: IY05249 COMPID: 5765C3403 REL: 430
ABSTRACT: SECURITY: BUFFER OVERFLOWS IN SNMPD

PROBLEM DESCRIPTION:
Anywhere, if the attacker can get a snmpd manager application
such as snmpinfo, by executing the command like:
snmpinfo -m dump -h victim -c
        awk 'BEGIN {for(i=0;i < 1200;i++) printf("x")}'
It can cause the snmpd daemon crash.

PROBLEM CONCLUSION:
In file src/tcpip/usr/sbin/snmpd/logging.c, function advise(),
it called:
vsprintf(buffer, msg_format, ap);
buffer is a fixed size buffer of 1024.
Since the value "ap" passed can be bigger than the buffer
size, it cause the snmpd core dump.
We use:
bzero(buffer, sizeof buffer);
vsnprintf(buffer, sizeof(buffer)-1, msg_format, ap);
It gurantees only 1023 bytes of infor will be copied to
buffer. Whatever after that will be truncated.

Hmm... that's only logging, and is from the January 2000 timeframe - does
this actually close all the *other* problems from the PROTOS tests as
well? I sort of doubt it was a "one fix does it".

IX76040 SECURITY: SNMPD LOG FILE FOLLOWS SYMLINKS
IY04865 SECURITY: NON-ROOT USERS CHANGE SYS INFO VIA SNMPD

Even older, and don't seem to address the issue either..

APAR: IY14378 COMPID: 5765C3403 REL: 430
ABSTRACT: SNMPD: REMOVE APAR IY09657 AS DEFAULT BEHAVIOR

PROBLEM DESCRIPTION:
snmpd will deny any set request if it comes from a port number
less then 1024 because the security feature is turned on
by default.
Without the security feature turned on, snmpd won't deny
any set request if it comes from a port number less then 1024.

Dec 2000, and doesn't look related...

APAR: IY19184 COMPID: 5765E6100 REL: 510
ABSTRACT: PTF:SNMP MONITOR GENERATES A NULL POINTER EXCEPTION.

APAR: IY20866 COMPID: 5765C3403 REL: 430
ABSTRACT: DUMPING TCP, UDP, ICMP, IP SUBTREE CAUSING MEMORY LEAK

APAR: IY23052 COMPID: 5765C3403 REL: 430
ABSTRACT: SNMPD CORE DUMPING IN AIX 4.3.3

(but this last only applies if you have a SysKonnect PCI FDDI).

Conclusion? IBM's been patching a lot, which is good - and they pass
the PROTOS tests, which is good. But I still haven't seen a good
"We fixed this in IYnnnnn" candidate, unless I missed one, or unless
it was one of these:

IX71277 SECURITY: VULNERABILITY IN LIBISODE.A (AIX 4.2 - ancient)
IX71478 SECURITY: VULNERABILITY IN LIBISODE.A (AIX 4.1 - even more so)

or it's filed under a non-security APAR against one of the *other*
shared libraries that 'dump -H /usr/sbin/snmpd' shows you..... 

-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech