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 - 13:41:15 PST