Nmap Development mailing list archives

Ncat/Nsock notification of connection reset


From: Daniel Miller <bonsaiviking () gmail com>
Date: Fri, 17 Mar 2017 23:41:34 -0500

List,

I've been digging through some bug reports from Red Hat, since they have a
huge base of users that have been using Ncat as the default netcat/nc for a
few years now. One bug in particular [1] has me thinking, and I need some
guidance from the Nsock gurus.

The bug report describes how a Ncat client that is connected to a server
which is killed with Ctrl-C is not notified that the connection is gone
until 2 lines have been entered. The cause, I discovered, is that even
after receiving EOF from the server, the client still has a right (and in
other situations, an ability) to send more data over the TCP connection.
But when it tries to do this (the first of the 2 lines), the server sends a
RST, which closes the client socket. Unfortunately, due to the way Ncat is
looping (or maybe Nsock?), there's no notification that the socket is
closed until Ncat tries to do a send on it (the second of the 2 lines) and
gets EPIPE/SIGPIPE.

I really think there ought to be some way to catch the fact that the server
has killed the connection. The first step would be making sure Nsock
notices this. With the default select engine [2], I don't see any
indication of the event with strace. But with the epoll engine, I think I
see something that looks like this:

epoll_wait(3, {{EPOLLERR|EPOLLHUP, {u32=13173952, u64=13173952}}}, 128, -1)
= 1

This is not present in other situations such as the first line sent after
the server is killed. So maybe we could do something with that?

The second step would be making Ncat handle the situation properly. Instead
of trying to read from STDIN, we could just exit, since the other side is
fully shut down.

Thoughts?
Dan

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1328996
[2] Should Ncat use a better engine than select by default, or does it not
matter?
_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/

Current thread: