Re: Bug in SMB when multiple scripts are connecting to same host

[Ron <ron () skullsecurity net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 14 Mar 2011 23:45:05 -0700 David Fifield <david () bamsoftware com> wrote:
> On Mon, Feb 28, 2011 at 01:44:34PM -0600, Chris Woodbury wrote:
> > Ron-
> >
> > Thanks for the response. Don't worry about the delay - 'better late
> > than never' is my motto ;). I hadn't thought of the lockout
> > implications of separate account lists; so, yes, you certainly
> > wouldn't want to go that route. With that in mind, I put some more
> > thought into it, and it seems to me that mutexes are the best
> > approach.
> >
> > I made a patch that adds mutexes to start_session_basic() and
> > start_session_extended(). My thinking was that the first script to
> > get there would be responsible for finding the right account (or
> > exhausting the possibilities), and that, once that was done, the
> > other scripts could follow along and already have that account
> > waiting for their get_account() call. I had to put in an "unlock"
> > before each of the short-circuit returns; so, it's not exactly
> > pretty, but it gets the job done.
>
> Could you rewrite this with wrapper functions to handle the mutexes,
> so as to get rid of the need to unlock at every single return? I'm
> afraid the way it's written now will be too hard to maintain.
>
> Ron, what do you think of Chris's solution?
>
> David Fifield
This scares me a little, because I've had some serious problems in the past with mutexes and deadlocks in the SMB code. 
But assuming it's implemented well, this is probably the best (only?) way to solve this particular issue. 

Ron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iEYEARECAAYFAk1/jo0ACgkQ2t2zxlt4g/RTUACfaZC1LQSFvisofgECOqXnciUp
8yAAoKuRSVMqrVGc6EenvzWGjOTVea1C
=qQ6j
-----END PGP SIGNATURE-----
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/