Re: Built-in authentication for http.lua

[Patrick Donnelly <batrick () batbytes com>]

On Thu, Aug 12, 2010 at 4:54 PM, David Fifield <david () bamsoftware com> wrote:
> On Sat, Jul 31, 2010 at 10:42:14AM +0200, Patrik Karlsson wrote:
> > I implemented a quick brute script to test the new authentication feature and found two problems.
> > One is related to caching and the other to calling the http lua with multiple worker threads.
> >
> > As my brute framework uses multiple worker threads to perform brute-forcing I noticed the following
> > error popping up at times:
> >
> > ./nselib/http.lua:874: do not have a lock on this mutex
> > stack traceback:
> >       [C]: in function 'mutex'
> >       ./nselib/http.lua:874: in function 'insert_cache'
> >       ./nselib/http.lua:1040: in function 'get'
> >       ./scripts/http-brute.nse:62: in function 'login'
> >       ./nselib/brute.lua:405: in function 'doAuthenticate'
> >       ./nselib/brute.lua:442: in function 'main'
> >       ./nse_main.lua:584: in function <./nse_main.lua:584>
> >
> > The error may be in how I'm calling the http lib from my code, I don't know.
> > Anyway, when running with a single thread it works great. In order to test this change the line       
> > engine:setMaxThreads(1) in http-brute to 10.
>
> I see this too. It seems to only happen at the end of the script. If I
> set unpwdb.timelimit=10s, it happens after 10 seconds, and with
> unpwdb.timelimit=20s, it happens after 20.
>
> I did some looking into this. The problem is that the http cache mutex
> is being freed twice. First by mutex_aux_done, which is defined in
> nse_nmaplib.cc and is "called when a thread ends but failed to
> unlock the mutex." It is then freed again in insert_cache by the http
> library.
>
> Patrick, do you have an idea why this is happening? I attached the patch
> that I used to diagnose it. The telltale parts are

I'm not sure after a cursory glance, no. I don't know how those
threads are still running insert_cache after their destructors are
called.

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