Re: [PATCH] [Ncat] Fix EOF handling

[David Fifield <david () bamsoftware com>]

On Tue, Jun 02, 2009 at 02:43:57PM -0700, Fyodor wrote:
> On Mon, Jun 01, 2009 at 06:13:11PM -0600, David Fifield wrote:
> > 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?
>
> Of course we need --chat too (you were probably including that in
> --broker) and we may want to keep the current behavior for UDP, unless
> you want to quit after the first UDP packet is received.  We could add
> a multi-connection option for normal listen mode if anyone finds a use
> case and asks for it.

I have attached a patch with one possible solution. Instead of allowing
only one connection, it allows multiple, but quits after the last one
disconnects.

I don't know, the more I think about it, the more I think that allowing
only one connection, and then quitting, in listen mode makes sense. That
makes it completely symmetrical with normal connect mode, where you make
one connection and hang on until the remote side closes it (or with
--send-only you can quit early on EOF from stdin).

If we limit it to one connection, then "ncat --listen" would be a mode
of operation quite distinct from "ncat --broker" (currently
ncat_listen.c and ncat_broker.c are very similar, so much so that I have
considered combining them). It would make sense to make --broker a peer
of --listen, not subsidiary to it, and deprecate the --broker --listen
option combination. Also "ncat --listen --exec", with its inetd-like
behavior, would be different code than ordinary "ncat --listen".

I looked through the Ncat guide to see what would be broken by this
change. I found:

http://nmap.org/ncat/guide/ncat-tricks.html#ncat-nmap-version
        ncat -l 5200 --hex-dump vscan.log > /dev/null
        Used one listening Ncat to handle multiple connections from -sV.
http://nmap.org/ncat/guide/ncat-simple-services.html
        ncat -l 9 --recv-only > /dev/null
        TCP discard server; could be worked around.
        yes "chargenchargenchargen" | ncat -l 19 --send-only
        chargen server; could be worked around.

Maybe it's time to get rid of the listen mode/connect mode dichotomy. If
--listen is modified to accept only one client, that would leave at
least these "modes," different enough to be essentially separate
subprograms:
        ncat            # Connect mode. Includes --exec and proxy connections.
        ncat --listen
        ncat --broker           # Includes --chat.
        ncat --listen --exec    # Includes --sh-exec
        ncat --listen --proxy-type http

The only difference now is that "ncat --listen" and "ncat --listen
--exec" are combined because they both handle multiple clients.

David Fifield

Attachment: ncat-listen-quit.diff
Description:

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