Re: Ncat and windows line endings

[Fyodor <fyodor () insecure org>]

On Thu, May 07, 2009 at 10:48:46PM +0100, jah wrote:
> I'd modified the Nmap code to produce the 13 (0x0D) in the error
> message.  Turns out that Ncat from a windows shell (also a cygwin shell
> which piggybacks the windows shell) sends \r\n as its line endings and
> the \r is appended to the command at the other end.  This prevents any
> command I've tried from working.  Conversely, a mingw shell sends \n as
> its line endings and this issue doesn't arise.
>
> I felt sure that something like this has been raised before, but haven't
> found anything pertinent.  Is this a known issue and, more to the point,
> can we afford to modify ncat to do something about it given that \r\n
> might have been sent as part of a HTTP GET, for example?

Hi Jah.  Excellent point.  I wish we there was a way we could
automatically detect and do "the right thing".  But as you noted,
passing \r\n straight through may be desirable in some cases
(e.g. writing HTTP requests) while changing \r\n to \n is desirable in
others (talking to a UNIX shell).  We should probably at least provide
options for both approaches.  We currently offer:

 -C, --crlf (Use CRLF as EOL)
    This option tells Ncat to try to use CRLF for line-endings if only
    an LF is found. This doesn't convert all LFs to CRLFs, only if
    it's at the end of the read buffer. This is useful for talking to
    some stringent servers directly from a terminal in one of the many
    common plain-text protocols which specify CRLF as the required EOL
    sequence.
    --http://nmap.org/ncat/man.html

First of all, maybe -C should format all bare \n in the buffer to
\r\n.  Is there a good reason (other than ease of implementation) for
only handling bare \n which happens to appear at the end of the
buffer?  Of course it needs to make sure that the \n chars in the
buffer are bare (not preceeded by a \r already).  We don't want to end
up with \r\r\n.

Second, we should probably have an option which does the opposite and
converts \r\n in input to plain \n.  Maybe it could be -N/--newline or
-L/--lf or something.  It should check the whole buffer for \r\n too,
IMHO.

Does anyone have a different idea or should we just implement these
two changes?  Anyone want to write a patch?

Cheers,
-F

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