"http-slowloris-check threw an error!" Was: [RFC] Crazy idea for deferring hosts in progress to a later hostgroup

[Daniel Miller <bonsaiviking () gmail com>]

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 what
> > we 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/