We at Snosoft have successfully duplicated the issues outlines on NUMBEROUS occasions... we are infact still going through code and playing. I have not had much luck exploiting snmpd on UCD-4.2.2 however snmptrapd seems to be a gold mine (integer overflows, format strings and regular overflows)! Email me if you are interested in helping further develop exploits or if you have more input or questions. An exploit WILL NOT be released at this time (by us at least). -KF foobat_private wrote: > > 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
This archive was generated by hypermail 2b30 : Thu Feb 14 2002 - 15:25:06 PST