Re: [PATCH] "ncat -l --send-only" not sending only

[David Fifield <david () bamsoftware com>]

On Fri, Jul 24, 2009 at 12:53:22PM -0600, David Fifield wrote:
> On Fri, Jul 10, 2009 at 04:06:43PM -0600, David Fifield wrote:
> > On Tue, Jun 30, 2009 at 05:27:52PM -0500, Kris Katterjohn wrote:
> > > David Fifield wrote:
> > > > On Sat, Jun 27, 2009 at 08:08:37PM -0500, Kris Katterjohn wrote:
> > > > > I created one patch to simply make Ncat behave like Netcat6 (which
> > > > > I think it should do).  But I figured having a choice in the matter
> > > > > is a lot better (since I seem to often have opinions on how things
> > > > > should behave which are different than that of many list members),
> > > > > which lead me to my current patch (attached) against the dev
> > > > > branch.  With this patch, --send-only's behavior does not change;
> > > > > however, you can now use the new --send-only=force to make it
> > > > > actually only send (or more specifically, not receive).
> > > >
> > > > I think that --send-only should work like the proposed
> > > > --send-only=force. It should do what its name suggests, and doing it
> > > > that way will probably simplify some code.
> > >
> > > Great!
> > >
> > > > The only thing is that I'm pretty sure connect and broker modes work the
> > > > same way. Can you make another patch that makes --send-only work like
> > > > Netcat6, with changes for connect and broker modes too?
> > >
> > > Connect-mode already wouldn't read from the socket if --send-only was used,
> > > but broker indeed had the same problem (I had just forgotten about it before).
> > >
> > > I've attached a patch to have --send-only cause Ncat to not read from the
> > > socket at all in plain listen and broker modes.
> >
> > Looks good, please commit it.
>
> I've found a bug with this. Try running
>
> ncat -l --send-only -vvv
> ncat localhost
>
> Then send something on the client. The server will start using 100% CPU
> as it repeatedly selects on the socket:
>
> Connection from 127.0.0.1.
> DEBUG: Added fd 4 to list, nfds 3, maxfd 4
> DEBUG: selecting, fdmax 4
> DEBUG: select returned 1 fds ready
> DEBUG: fd 4 is ready
> DEBUG: selecting, fdmax 4
> DEBUG: select returned 1 fds ready
> DEBUG: fd 4 is ready
> DEBUG: selecting, fdmax 4
> DEBUG: select returned 1 fds ready
> DEBUG: fd 4 is ready
> ...
>
> Connected sockets should not even be added to the select sets. However,
> it's not that easy, because the code overloads the meaning of the select
> sets to be two things: 1) a list of sockets to listen for activity on,
> and 2) a list of sockets to broadcast data to. So if a socket is not
> being listened to, it won't receive any data from the server either.
>
> This would not be hard to fix. It would just take having two lists of
> socket descriptors, one to listen to read events and one to keep a list
> of clients to broadcast to.

This bug is fixed in r15829.

David Fifield

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