Re: Ncat Windows send-only file EOF problem

[David Fifield <david () bamsoftware com>]

On Mon, Mar 01, 2010 at 12:05:01PM -0500, Zwirko, Andy wrote:
> Good day - I'm having a similar problem to:
>
> http://seclists.org/nmap-dev/2009/q3/605
>
> There was no resolution last year, just a response it couldn't be
> reproduced.  I seem to be able to reproduce a similar problem.
>
> The issue I'm having is when running ncat 5.21 on Windows XP SP3 it does
> not close the connection upon EOF when sending a file using the
> --send-only option.   I've reproduced this on several Windows XP SP3
> machines under cmd.exe, e.g. on the same machine and between 2 different
> machines.
>
> Here's ncat verbose output:
>
> RECEIVER:
>
> H:\>ncat -vvv -l > newfile
> Ncat: Version 5.21 ( http://nmap.org/ncat )
> Ncat: Listening on 0.0.0.0:31337
> NCAT DEBUG: Initialized fdlist with 102 maxfds
> NCAT DEBUG: Added fd 1936 to list, nfds 1, maxfd 1936
> NCAT DEBUG: Added fd 0 to list, nfds 2, maxfd 1936
> NCAT DEBUG: Initialized fdlist with 100 maxfds
> NCAT DEBUG: selecting, fdmax 1936
> NCAT DEBUG: select returned 1 fds ready
> NCAT DEBUG: fd 1936 is ready
> Ncat: Connection from 127.0.0.1.
> NCAT DEBUG: Added fd 1900 to list, nfds 3, maxfd 1936
> NCAT DEBUG: Added fd 1900 to list, nfds 1, maxfd 1900
> NCAT DEBUG: selecting, fdmax 1936
> NCAT DEBUG: select returned 1 fds ready
> NCAT DEBUG: fd 1900 is ready
> NCAT DEBUG: selecting, fdmax 1936
> NCAT DEBUG: select returned 1 fds ready
> NCAT DEBUG: fd 1900 is ready
> NCAT DEBUG: selecting, fdmax 1936
>
> SENDER
>
> C:\Program Files\Nmap>ncat --send-only localhost -vvv <  ZENMAP_README
> Ncat: Version 5.21 ( http://nmap.org/ncat )
> NSOCK (0.2030s) TCP connection requested to 127.0.0.1:31337 (IOD #1) EID
> 8
> NSOCK (0.2030s) Callback: CONNECT SUCCESS for EID 8 [127.0.0.1:31337]
> Ncat: Connected to 127.0.0.1:31337.
> NSOCK (0.2030s) Read request for 0 bytes from IOD #2 (peer unspecified)
> EID 18
> NSOCK (0.2180s) Callback READ SUCCESS for EID 18 (peer unspecified)
> (2048 bytes)
>
> NSOCK (0.2180s) Write request for 2048 bytes to IOD #1 EID 27
> [127.0.0.1:31337]
> NSOCK (0.2180s) Callback: WRITE SUCCESS for EID 27 [127.0.0.1:31337]
> NSOCK (0.2180s) Read request for 0 bytes from IOD #2 (peer unspecified)
> EID 34
> NSOCK (0.2180s) Callback READ SUCCESS for EID 34 (peer unspecified) (212
> bytes)
> NSOCK (0.2180s) Write request for 212 bytes to IOD #1 EID 43
> [127.0.0.1:31337]
> NSOCK (0.2340s) Callback: WRITE SUCCESS for EID 43 [127.0.0.1:31337]
> NSOCK (0.2340s) Read request for 0 bytes from IOD #2 (peer unspecified)
> EID 50
>
> I can Ctrl-C on the sender to end the connection and that closes the
> receiver, but otherwise the two will just sit and hang there waiting.
> It appears that the transfer is OK since the file sizes are identical.

Thanks for this report. I looked at the problem more closely and found
that I couldn't reproduce the problem when the program was compiled in
debug mode on my computer, but it could reproduce it when compiling in
release mode, or using the binaries from nmap.org.

The problem was a stack variable that was uninitialized in the case of
an EOF. I think that in debug mode, the stack variable was being filled
with a non-zero bit pattern. This caused the function to return true and
allow select to see the EOF. In release mode, the variable was left set
to 0, causing the function to return false. Actually I could get it to
return true sometimes by perturbing other function calls and leaving
different values on the stack.

This is fixed for the next release.

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