Bypassing Input Validation and Attack Detection

Windows 2000 SNMP DOS

While not an exceptionally exciting bug, this issue illustrates the principles behind the instrumented investigation technique pretty well. The relevant Microsoft Knowledge Base article can be found at http://support.microsoft.com/default.aspx?scid=kb;en-us;Q296815 , and the NGS advisory can be found at www.nextgenss.com/advisories/snmp_dos.txt .

In a moment of boredom while testing some SNMP walk code (common to SNMP implementers), we decided to see whether we could cause an overflow in the Microsoft SNMP daemon. We went through the usual process of attaching a debugger, RegMon, and FileMon; taking a quick peek at HandleEx to see what resources the SNMP daemon had open ; and using Performance Monitor to keep a track of what resources the SNMP process was using ”and then we ran a few quick tests, firing off some manual requests with a malformed BER structure (lengths not corresponding correctly and so on). Little appeared to happen, so we took a peek at which SNMP OID s were present when we walked the entire tree.

Again, nothing terribly interesting seemed to be present, but then when we went back into Performance Monitor we noticed that the daemon had apparently allocated about 30MB of memory.

Running another SNMP walk, the SNMP process again allocated a large amount of memory. We then stepped through the SNMP walk code, keeping a close eye on the amount of memory allocated by the SNMP process. We found that the problem appeared to occur when requesting printer- related values in the LanMan mib .

It turns out that a single SNMP request (that is, a single UDP packet) causes an allocation of 30MB. It's ridiculously easy (and very quick) to consume all available memory this way, with a few thousand packets, and the entire server is crippled ”no new processes will start, no new windows will be created, and if anyone attempts to log in (perhaps in order to attempt to shut down the SNMP service or the server itself), they will fail because the Microsoft Graphical Identification and Authentication (GINA), the DLL that controls logins, doesn't have enough memory available to create the dialogs it needs in order to obtain the user 's credentials. The only way out is to power down.

So in this case, discovery of the bug was based on closely observing memory usage in the target process. If we hadn't been looking at the memory usage, we'd never have seen the bug.