Nmap Development mailing list archives

Re: Hang on SNMP script?


From: Abuse 007 <abuse007 () gmail com>
Date: Wed, 19 Sep 2012 20:15:23 +1000

I have seen many NSE scripts exhibit behaviour like this, where they
do not terminate after a significant amount of time. A global timeout
limit, retry limit, or some mechanism to be able to terminate/fail an
individual script or similar would be nice. Cancelling nmap can mean
that results are lost because the block was not completed and saved to
one of the logs (nmap, gnmap, xml).

What I have done sometimes as a work around is insert a FW rule to
drop the traffic, which breaks the infinite loop, without losing
information that may have taken a long time to collect (useful when
there is not enough time to start the scan again).

A a side note, from what I can tell NSE is not threaded, (not sure
about the rest of nmap), and some scripts can be CPU bound rather than
network-bound. Making NSE multi-threaded or multi-processing would
allow it to scale better on multi-processor/core systems.



On Wed, Sep 19, 2012 at 8:18 AM, David Fifield <david () bamsoftware com> wrote:
On Thu, Sep 13, 2012 at 04:38:52PM -0500, Christopher Clements wrote:
More info on the specific script running:

NSE Timing: About 99.99% done; ETC: 16:38 (0:00:04 remaining)
NSE: Running: 'snmp-win32-software' (thread: 0x69e6d20)
        stack traceback:
                [C]: in function 'send'
                /usr/local/bin/../share/nmap/nselib/snmp.lua:479: in
function 'snmpWalk'

.../local/bin/../share/nmap/scripts/snmp-win32-software.nse:96: in function
<.../local/bin/../share/nmap/scripts/snmp-win32-software.nse:84>
                (...tail calls...)


---------- Forwarded message ----------
From: Christopher Clements <christopher.a.clements () gmail com>
Date: Thu, Sep 13, 2012 at 4:36 PM
Subject: Hang on SNMP script?
To: nmap-dev () insecure org


I've been running an internal scan for the past 24 hours with the following
options:

nmap -A -vvv -sSUCV --reason --open <targets>


however, it seems to be hung at this point for the past 12:

NSE Timing: About 99.99% done; ETC: 16:31 (0:00:03 remaining)
Stats: 22:15:16 elapsed; 52 hosts completed (128 up), 128 undergoing Script
Scan
NSE: Active NSE Script Threads: 1 (0 waiting)


If I increase to debug level 3, I have seen these messages happening for
the past 12 hours:

00000000: 30 2b 02 01 00 04 06 70 75 62 6c 69 63 a2 1e 02 0+     public
00000010: 02 6f 0c 02 01 05 02 01 01 30 12 30 10 06 0c 2b  o       0 0   +
00000020: 06 01 02 01 19 06 03 01 05 81 68 05 00                    h

00000000: 30 2b 02 01 00 04 06 70 75 62 6c 69 63 a1 1e 02 0+     public
00000010: 02 6f 0c 02 01 00 02 01 00 30 12 30 10 06 0c 2b  o       0 0   +
00000020: 06 01 02 01 19 06 03 01 05 81 68 05 00                    h

00000000: 30 2b 02 01 00 04 06 70 75 62 6c 69 63 a2 1e 02 0+     public
00000010: 02 6f 0c 02 01 05 02 01 01 30 12 30 10 06 0c 2b  o       0 0   +
00000020: 06 01 02 01 19 06 03 01 05 81 68 05 00                    h

00000000: 30 2b 02 01 00 04 06 70 75 62 6c 69 63 a1 1e 02 0+     public
00000010: 02 6f 0c 02 01 00 02 01 00 30 12 30 10 06 0c 2b  o       0 0   +
00000020: 06 01 02 01 19 06 03 01 05 81 68 05 00                    h

00000000: 30 2b 02 01 00 04 06 70 75 62 6c 69 63 a2 1e 02 0+     public
00000010: 02 6f 0c 02 01 05 02 01 01 30 12 30 10 06 0c 2b  o       0 0   +
00000020: 06 01 02 01 19 06 03 01 05 81 68 05 00                    h

I see alternation between a1 and a2 in this column ↑↑
According to snmp.lua, these are "Get Next" and "Get Response". It seems
that the OID is not changing each time, though.

Please try this patch and we can see what OIDs are being tried. An OID
comparison is controlling the exit from the loop in snmpWalk.

David Fifield

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/

Current thread: