Re: Always practice safe software: a lesson from UnrealIRCd

[Ron <ron () skullsecurity net>]

On Tue, 22 Jun 2010 14:05:56 -0600 David Fifield
<david () bamsoftware com> wrote:
> Yes, but at that point you are at least assured that your script
> holds a socket. My bet is that almost all of the excessive delay is
> scripts waiting for a socket. NSE only allows 20 scripts to hold a
> socket at a time, so others must wait until an earlier script gives
> up all its sockets. I think this waiting is what's taking up most of
> the time.
>
> There aren't any timeslices. Your script has exclusive control of the
> processor until it reliquishes it with a socket operation or sleep. It
> gets called back as soon as the socket operation finishes though
> (unless another script is refusing to yield).
>
> You'll only be timing the very small delay imposed by the NSE
> scheduler, and not the very long delay waiting for a socket to be
> free.
>
> David Fifield

Sadly, the solution of starting the timer immediately after tryssl() doesn't solve the problem (although I'm pretty 
sure it helps). 

> From manual testing, there are practically no vulnerable hosts in that list. It is common for individual hosts to take 
> 10-20 seconds to return, though, even if I change the delay to 30 seconds (proving that they are taking 10-20 seconds 
> on their own, not because of the delay I introduced). 

I think the only way to do this well is by somehow forcing this script to only run one at a time. When I get home I'll 
try wrapping the whole thing in a mutex and see if that helps. 

Ron

-- 
Ron Bowes
http://www.skullsecurity.org
http://www.twitter.com/iagox86

Attachment: _bin
Description:

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