Nmap Development mailing list archives

Re: [PATCH] [Ncat] Fix EOF handling


From: Fyodor <fyodor () insecure org>
Date: Tue, 2 Jun 2009 14:43:57 -0700

On Mon, Jun 01, 2009 at 06:13:11PM -0600, David Fifield wrote:
On Sun, Apr 19, 2009 at 10:56:50PM +0200, Daniel Roethlisberger wrote:

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.

That is fairly troubling.  I can think of many reasons for having
multiple simultaneous connections to ncat, but they mostly unravel
when considered in light of the intermingled content issue.  People
still might find it useful for sending short status/log messages or
the like, as the chance of intermingled output might be very low.  But
I don't think this hypothetical usage overcomes the clear drawback of
certain pipe recipients behaving poorly in this situation.

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 think hd should probably check it's buffers at SIGINT and print
anything which remains before it quits, but I'll bet many programs
share this limitation and we can't fix them all.

I'll add this issue to docs/TODO

-F

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


Current thread: