Re: possible ncat handle leak

[David Fifield <david () bamsoftware com>]

On Thu, Jan 07, 2010 at 12:14:01AM +0000, Jon Greaves wrote:
> Hi,
>
> I've just been looking at a copy of ncat (5.10BETA2 on both Windows XP and Windows 2003)  I have running to redirect 
> port 143 connections and it looks like there may be a handle leak somewhere running handle.exe against the ncat 
> process before and after a connection and this is the difference
>
>   6C4: Thread        <Non-existant Process>(7352): 6204
>
> Ncat command I'm running is below
>
> ncat -l server1 143 --max-conns 100 --sh-exec "ncat --ssl imap.gmail.com 993"

Thanks fro reporting this. I've been checking this out using Process
Explorer from Sysinternals from
http://technet.microsoft.com/en-us/sysinternals/default.aspx. Ncat is
not really leaking a handle here, it's just that the ncat subprocess is
not exiting. The "ncat --ssl" command is still talking to the IMAP
server even though the ncat that spawned it has lost its client
connection. While in this case it would make sense to authmatically kill
the subprocess, I don't think it makes sense in every case.

If you run a command to end the IMAP session, I think you will find that
the handles are reclaimed. Correct me if I'm wrong. I tried this:

$ ncat 192.168.0.190
* OK Gimap ready for requests from ... 4if3717676pxi.101
abcd LOGOUT
* BYE Logout Requested 4if3717676pxi.101
abcd OK Quoth the raven, nevermore... 4if3717676pxi.101

The parent Ncat closes the child process's stdin when the client
connection is lost, which will cause many programs to end. Ncat itself
is a little different in that it doesn't quit when its stdin is closed.
This same behavior happens on Unix.

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