Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Re: Call for testing: "ncatins" Ncat feature
From: David Fifield <david () bamsoftware com>
Date: Thu, 15 Aug 2013 00:30:45 -0700

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/


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault