Ncat/Nsock notification of connection reset

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Ncat/Nsock notification of connection reset

Daniel Miller-10
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
[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/
Reply | Threaded
Open this post in threaded view
|

Re: Ncat/Nsock notification of connection reset

Frank Bergmann
On Fri, Mar 17, 2017 at 11:41:34PM -0500, Daniel Miller wrote:
>    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

Hi Daniel,

ucspi-ssl had a long time issue causing high load when the *client*
connection was resetted because a fast loop of poll() (not epoll) and
read() did happen.

Here the issues was that on connection reset poll() delivered an "IN" event
but the read() after it only delivered 0 bytes / EOF. The fix HERE was to
just check for 0 bytes after IN. Erwin Hoffmann applied my proposed patch
for 0.98. (I detected the issue on linux i386 and x86_64.)

More information I found here:
https://sourceware.org/bugzilla/show_bug.cgi?id=13660

Frank


_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/
Reply | Threaded
Open this post in threaded view
|

Re: Ncat/Nsock notification of connection reset

Henri Doreau
In reply to this post by Daniel Miller-10
2017-03-18 5:41 GMT+01:00 Daniel Miller <[hidden email]>:

> 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
>

Hi Dan,

this bug has been there forever, but I don't believe anyone relies on
that behavior in a way or another[1], so let's fix it.

I can see three things:

* First, nsock internal handling of EV_EXCEPT is half broken (and it's
my fault) . It should be an output flag (ie. automatically watched and
returned) and nsock_core should check it systematically.

* Second, about ncat using select by default. It can indeed work with
others but select is the only nsock engine that works for stdin on
windows - thanks to our fselect wrapper in nbase - and also if stdin
is a file on unix like (ncat localhost < somefile) which are the two
tricky cases IIRC. I wouldn't change that.

* Ncat read handler can exit on EOF on the socket but only in
recv-only mode or non-TCP. I don't think we really want that (needs
more thoughts though). Commenting that check out and a dirty-fix of
nsock internals seems to resolve the issue. Ncat client exits as soon
as the RST from the dying server is received.


HTH

[1] (the obligatory xkcd) https://xkcd.com/1172

--
Henri
_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/
Reply | Threaded
Open this post in threaded view
|

Re: Ncat/Nsock notification of connection reset

Henri Doreau
2017-03-18 23:15 GMT+01:00 Henri Doreau <[hidden email]>:
> Commenting that check out and a dirty-fix of
> nsock internals seems to resolve the issue. Ncat client exits as soon
> as the RST from the dying server is received.
>

Please find the aforementioned patch attached. Requires adjustments &
cleanup but should be a good starting point.

Regards

--
Henri

_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/

nsock_ev_except_basefix.patch (10K) Download Attachment