Re: netcat as both client and server and communicating both ways

[Daniel Miller <bonsaiviking () gmail com>]

Blaise,

For as simple an idea as netcat is, implementing it is remarkably complex.
We have already dealt with nearly every combination of EOF behavior
possible [1], but this is a new one.

Here's what's going on: when Ncat's server sees EOF (read of 0 bytes) on
the socket, it quits immediately. This is within control of Ncat because
Ncat is intercepting all the socket reads and passing the results on to the
exec'd process. Traditional netcat instead replaces its own stdin and
stdout with the socket file descriptor before exec'ing the process, so the
process is in complete control over when it closes. /bin/cat does not shut
down until it has finished writing out any data it has read in, which is
why you always get the response back. Under Ncat, however, the socket EOF
causes us to shut down regardless of what the process wants to do.

Now, it's not as simple as just copying traditional-netcat's behavior. Ncat
does what it does because it has to handle all sorts of more unusual
circumstances: SSL, Telnet negotiation, line delays, timeouts, etc. These
are important features.

However, I think we can probably improve things. We can change Ncat to not
bail when the socket gives EOF, but to close the exec'd process's stdin and
see what it does. When the process closes (or if a write to the socket
fails), we can finish closing the socket. The relevant functions are
netexec in ncat_posix.c and subprocess_thread_func in ncat_exec_win.c. They
are very similar in this particular area, though some of the functions they
call are different (WaitForSingleObject instead of select, etc.).

We would welcome a timely patch to do this. Relevant issue:
https://github.com/nmap/nmap/issues/962

Note that this is the same behavior that has been discussed previously, but
apart from the -c (shell execute) feature. That discrepancy is harder to
deal with because we can't just rely on the behavior of some other process
to decide what to do with the socket. Better description here:
http://seclists.org/nmap-dev/2013/q1/227

Dan

[1] https://secwiki.org/w/Ncat/EOF_behavior

On Tue, Aug 8, 2017 at 5:07 PM, Blaise R. <rex2k8 () gmail com> wrote:

> I originally asked Fyodor about this via email and he directed me here. I
> think my first email got lost in spam filter because I sent it before I was
> on the list.
>
> Here is the original email:
>
> Hello.
>
> I have a problem with the nmap's ncat, the latest one on Fedora 25, I it
> was 7.40.
> I also compiled 7.50 from sources but the results are all the same.
>
> I realize that I can get echo in many different better ways, this is just
> a distilled down example of a bigger thing I'm attempting to do.
>
> Basically, I use as the server: nc -kl 1234 -c cat
> and as the client: echo 'w' | nc localhost 1234
> It doesn't output the w back to me.
>
> I have tried a server with nc that just reads the input and echos back an
> HTTP header and content and it worked when using a web browser as a client.
>
> I have also tried running just: nc localhost 1234
> And I'm able to interactively enter lines and get them back.
>
> There is also a service called seashells.io, doing: echo 'w' | nc
> seashells.io 1337
> also works and this is the behavior I'd want to achieve.
>
> It looks like some sort of issue when there is nmap's ncat on both client
> and server.
>
> I'd appreciate any response (known bug, won't fix, will fix, patches or
> deeper research welcome, etc.) at all.
>
> Best regards.
>
> _______________________________________________
> Sent through the dev mailing list
> https://nmap.org/mailman/listinfo/dev
> Archived at http://seclists.org/nmap-dev/
_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/