[NSE] Concerning locals in scripts, environments, and globals

["Patrick Donnelly" <batrick.donnelly () gmail com>]

Diman Todorov and I located a problem in the current script system
that had scripts (from the same file, e.g. bruteTelnet.nse) sharing
the same locals which may have caused some bugs in scripts that were
hard to trace. Currently, all threads for a script share the same
action closure and thus all of its upvalues. If any of these upvalues
hold something like a socket, problems will arise when threads attempt
to open/close/manipulate a socket via this upvalue. An example of this
problem is in bruteTelnet.nse:
<code>
  local soc
  local catch = function() soc:close() end
  local try = nmap.new_try(catch)
</code>

These locals were placed outside the action closure because multiple
local functions manipulate the same socket. There are two solutions
but only one is viable at this point. The first is to move these
socket locals into the action closure along with each local function
that makes use of these socket locals. The second is to change the
system to create a new action closure for each thread made for a
script. Because the first change is fairly involved, can be confusing,
and would require a fairly large and complicated change to some
scripts, we have chosen the second option.

I will be changing NSE to reexecute the file closure for each thread.
This will create a new action closure along with its local sockets (if
there are any). People should be aware this change means that local
variables will no longer be shared across threads of the same script.
The recommended way to share information between scripts is still
nmap.registry. Further, each thread will now have its own environment
and therefore I will be releasing the restriction on globals being
"unmodifiable" after the script has been loaded.

Cheers,

-- 
-Patrick Donnelly

"One of the lessons of history is that nothing is often a good thing
to do and always a clever thing to say."

-Will Durant

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