Exploiting SNMP?

[<foob () return0 net>]

Has anyone tried exploiting the SNMP problems disclosed in the recent CERT
notice, and original investigated by the University of Oulu?

http://www.cert.org/advisories/CA-2002-03.html
http://www.ee.oulu.fi/research/ouspg/protos/testing/c06/snmpv1/index.html

Running the supplied java applet against Windows 2000 causes no service
failure, and no noticable impact on the system.  Sending the raw packet
data to UDP 161 has the same null impact.

On Solaris (7, sparc), the snmpdx agent either stops responding after
certain requests (the deamon stays active, but the MIB is not browsable
anymore), or the daemon aborts with a Bus Error.  This latter case can
only be triggered by one packet (#5922) as far as i can tell.  Whats more,
it doesnt always abort - if some snmpdx is healthy, and has been servicing
valid requests this packet has no impact.  

If I understand SNMP correctly, the data in this particular packet
specifies a long OID (by setting each section to some maximum value) and
also specifies a format string (%s%x%n) in the value portion.  Replacing
the format string with 'abcdef' does not affect the impact - indicating
that the OID is causing the SIGBUS, not the format string.

Yes the stack is corrupted, with data supplied in the OID.  
But the SIGBUS is caused by attempting to dereference the a register
containing data from the OID.  If this can be bypassed, eventually the
program will jump to our specifiedd location.

The problem (perhaps just my limitied knowledge of SNMP and sparc) is that
the data in the packet cannot be modified greatly - most changes to the
'interesting' parts of the OID do not impact the snmpdx service.

Is anyone else looking at exploiting these issues?  

The fact i cant recreate the MS problem is a little worrying - they've
released patches, but from here it didnt even look vulnerable!

If people are interested in / working on this, I can forward some more
information on the solaris problem. 

- foob