Nmap Development mailing list archives
"http-slowloris-check threw an error!" Was: [RFC] Crazy idea for deferring hosts in progress to a later hostgroup
From: Daniel Miller <bonsaiviking () gmail com>
Date: Sun, 5 Apr 2015 16:25:29 -0500
On Sun, Apr 5, 2015 at 8:02 AM, Gisle Vanem <gvanem () yahoo no> wrote:
David Fifield wrote: No targets are considered slow. (No targets are deferred.) That's whatwe have now. Slow targets block the flow and prevent other targets from starting.Speaking of "slow", the http-slowloris-check.nse script seems to have an issue. I know next to nothing about LUA, but on this command: nmap -p80 -P0 -sT --script=http-slowloris-check.nse 93.184.219.29 (scam-site at www.ibmoffice.webeden.co.uk) results in this: NSE Timing: About 0.00% done NSE: http-slowloris-check against 93.184.219.29:80 threw an error! EOF stack traceback: [C]: in function 'try' f:\MingW32\src\inet\nmap/scripts\http-slowloris-check.nse:116: in function <f:\MingW32\src\inet\nmap/scripts\http-slowloris-check.nse:107> NSE Timing: About 33.33% done; ETC: 12:47 (0:03:02 remaining) NSE: http-slowloris-check against 93.184.219.29:80 threw an error! EOF stack traceback: [C]: in function 'try' f:\MingW32\src\inet\nmap/scripts\http-slowloris-check.nse:135: in function <f:\MingW32\src\inet\nmap/scripts\http-slowloris-check.nse:124> NSE: [http-slowloris-check 93.184.219.29:80] Time difference is: 10 ... Nmap scan report for 93.184.219.29 Host is up, received user-set (0.047s latency). Scanned at 2015-04-05 12:43:10 CET for 101s PORT STATE SERVICE REASON 80/tcp open http syn-ack | http-slowloris-check: | VULNERABLE: | Slowloris DOS attack | State: LIKELY VULNERABLE -------- Not sure what happens. But since I get a "LIKELY" result, I assume the script-error is not important. Or maybe this is a false positive? Can someone try the above command on Linux?
Gisle, This is an unfortunate side-effect of a clever language hack that NSE scripts use to mean "If this call fails, clean up and return immediately." The symptom is a traceback that begins: stack traceback: [C]: in function 'try' The nmap.new_try [1] function returns a closure which can be used to simplify error-checking code within an NSE script. The "end the script thread immediately" functionality is implemented as a Lua error (C long jump), so this stack trace gets printed, which is not ideal. There are no plans to improve it, but my main gripes are: 1. The "try" and "catch" language is wrong, since the "exception" is not caught but just wrapped in a cleanup function. 2. They are reported as errors, when in reality the use of the "try" function means that a failure condition is explicitly allowed and handled. Dan
_______________________________________________ Sent through the dev mailing list https://nmap.org/mailman/listinfo/dev Archived at http://seclists.org/nmap-dev/
Current thread:
- "http-slowloris-check threw an error!" Was: [RFC] Crazy idea for deferring hosts in progress to a later hostgroup Daniel Miller (Apr 05)