--lua-exec stream redirection on Windows

[David Fifield <david () bamsoftware com>]

Jacek recently posted an announcement of the --lua-exec option:
http://seclists.org/nmap-dev/2013/q2/487
Right now, it works only for non-Windows systems. It's implemented as
the usual fork with redirected stdin and stdout to run an embedded Lua
interpreter. This is harder on Windows because fork doesn't exist. For
the existing --exec and --sh-exec, we use the CreateProcess function
that allows redirecting input and output, but in the case of --lua-exec,
there's no new process to start, just a function to call in a thread.

Jacek is trying the approach of reassigning Lua's io.stdin and io.stdout
variables before running the requested program. This is a bit
problematic because, as Patrick noted, there are other places where
stdin and stdout can leak, for example io.lines called with no
arguments. But perhaps with enough tweaking this idea will work.

Another possibility is to actually create a new process--calling
ncat.exe in a special way so as to make it a Lua interpreter. This would
allow us to use CreateProcess and all the debugged and tested
infrastructure we have for --exec and --sh-exec. What I mean is that you
as a user would call
        ncat -l -k 5000 --lua-exec test.lua
and the code in ncat_exec_win.c would do
        CreateProcess("ncat --lua-exec-internal test.lua", ...);
The --lua-exec-internal option will cause Ncat to immediately become
just a Lua interpreter. It would be basically the same as "lua test.lua".
This is something like how scp has the undocumented -t option that makes
it a file receiver: https://en.wikipedia.org/wiki/Secure_copy#How_it_works.

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