Re: Call for testing: "ncatins" Ncat feature

[David Fifield <david () bamsoftware com>]

On Wed, Aug 07, 2013 at 06:19:20PM +0200, Jacek Wielemborek wrote:
> The reason for this is that although you can read and write to the
> socket (and even output messages using standard error stream), there's
> no way to read Ncat's standard input.
>
> That's when ncatins come in. The idea behind them is to allow the user
> (or rather - the program ran using --exec, --sh-exec or --lua-exec) to
> open Ncat's standard input/output and read/write to it as you would to
> any other file. In order to do that, Ncat exports a new pair of
> environment variables - depending on the system, you'd get
> NCAT_INPUT_FD and NCAT_OUTPUT_FD on Linux, or NCAT_INPUT_PIPE and
> NCAT_OUTPUT_PIPE on Windows. On Linux, the values of the variables
> point to numbers of file descriptors ready for opening in order to
> read/write to Ncat's standard streams - just call fdopen() and you're
> set. On Windows, due to its limitations, there's a bit more dancing
> involved - you need to connect to the named pipe, with the filename
> from the environment variable.

Here's some more background on the ncatins idea. Ncat lets you execute a
command using various options (http://nmap.org/ncat/guide/ncat-exec.html).
How these options work is that Ncat receives a connection from or makes
a connection to a remote host, then reassigns the command's stdin and
stdout to point at the network socket. So a previously oblivious program
that knew only how to read from stdin and write to stdout can start
interacting with a network.

What these executed commands don't have access to is Ncat's actual own
stdin and stdout; i.e., the terminal. If you wanted to have a program
that could interact with the network on its own stdin and stdout, but
also read from the keyboard and write to the terminal, there wasn't a
way to do it with Ncat.

The ncatins plan is to provide executed commands with a copy of Ncat's
stdin and stdout. We do this by setting environment variables with the
file descriptor number of the streams, for instance NCAT_INPUT_FD=4. So
for example, if the program you run is a shell script, you could write
to Ncat's stdout like this:
        echo "$line" >$NCAT_OUTPUT_FD
(On Windows, we couldn't figure out how to share descriptor/handle
numbers in this way, so instead you get something like
NCAT_INPUT_PIPE="\\.\pipe\ncatin-1234-0".)

The main motivation behind this new feature was to enable more advanced
filter-like programs to be run. I thought that an execution model, where
the command usurps control from Ncat, and only uses the parent Ncat
process as a kind of networking library, was a bad fit for the proposed
filters. I wrote some of my thinking at https://secwiki.org/w/Talk:Ncat-Lua.
It appears that Jacek's new branch ncat-lua-callbacks will be a better
way to implement the proposed filters.

> svn co https://svn.nmap.org/nmap-exp/d33tah/ncat-env-ncatins
> cd ncat-lua
> ./configure
> make
> cd ncat
> ./ncat --listen --lua-exec scripts/hello-ncatout.lua
> # And, in another terminal...
> ./ncat localhost
> # (now type in some text in the first terminal and hit return)

The above said, there may be other uses for NCAT_INPUT_FD and
NCAT_OUTPUT_FD beyond writing input/output filters, so I'd encourage
people to speak up about this feature and branch.

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