Re: [PATCH] [Ncat] Fix EOF handling

[David Fifield <david () bamsoftware com>]

On Sun, Apr 19, 2009 at 10:56:50PM +0200, Daniel Roethlisberger wrote:
> David Fifield <david () bamsoftware com> 2009-04-19:
> > So it's hard to pick a good default. The documentation at
> > http://nc110.sourceforge.net/ has not quitting on EOF as a feature:
> >     You may be asking "why not just use telnet to connect to
> >     arbitrary ports?" Valid question, and here are some reasons.
> >     Telnet has the "standard input EOF" problem, so one must
> >     introduce calculated delays in driving scripts to allow network
> >     output to finish.
> > Then there is a -w <secs> option to quit after some period of
> > inactivity.
> >
> > I don't have experience with earliers Netcats so I don't know what's
> > best. I guess my bias would be to leave connections running by default,
> > and add a switch to close on stdin EOF, the reason being that in case of
> > user error it's better to receive extra data than to potentially throw
> > data away.
>
> Current default behaviour actually seems to *loose* data on
> SIGINT because of buffering.  I tried sending an odd number of
> bytes to an Ncat listener piping into hexdump (hd).  The last few
> bytes never made it to hexdump after pressing Ctrl+C.  Same thing
> with other consumers such as tar.

I looked into this. Indeed, if you send the hexdump listener a number of
bytes that is not a multiple of 16, and kill the client, and even kill
the server, hexdump never prints the last remaining bytes. However I
found that the server does pass every last byte to hexdump, which you
can confirm with
        ncat -l | cat -u
or some similar unbuffered command.

The bytes are making it to hexdump (or tar, or whatever), but once there
they wait in a buffer until more bytes come in or the end of the stream
is found. Because of the way Ncat works, accepting input from multiple
clients and sending it to a common sink, it never closes its own stdout,
which would signal hexdump to print its remaining output. Closing stdout
on SIGINT doesn't work, because hexdump gets the SIGINT too and dies
before it can handle the end of stream. Traditional Netcat doesn't have
this problem because it only accepts one connection; when the connection
ends, it can close its stream and exit.

This is fairly troubling. Having multiple simultaneous connections is
nice for --sh-exec and connection brokering, but I haven't thought of a
use for it in normal listen mode. If you're doing a file transfer for
example, and someone else starts sending a file to the server at the
same time, the contents of the files will be intermingled:
        ncat -l
        yes a | ncat localhost
        yes bb | ncat localhost
Plus it makes us potentially lose bytes at the end of a stream when
writing to a pipe. I don't mean to suggest this is the only solution,
just the first one I thought of, but what do you think about accepting
only one connection in listen mode without --broker and --exec?

David Fifield

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