lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
From: thalm at (thalm)
Subject: Strange netcat behavior

Yes, that is correct.
But my point is why does netcat defaults to a LF behavior (don't know if there is the option of sending CRLF instead of LF) and telnet defaults defaults to CRLF ?
netcat is very much used to "talk" to HTTP servers. So why does netcat does not use by default CRLF ?
Again, this breaks HTTP RFC rules concerning HTTP server and HTTP client behavior...

	-----Original Message----- 
	From: [] 
	Sent: Fri 10/17/2003 2:58 PM 
	To: thalm 
	Subject: RE: [Full-Disclosure] Strange netcat behavior

	I could be mistaken, but isn't sending a CR optional in telnet ??
	Microsoft Windows 2000 [Version 5.00.2195]
	(C) Copyright 1985-2000 Microsoft Corp.
	Microsoft Telnet> SET /?
	NTLM            Turn ON NTLM Authentication.
	TERM x          (where x is ANSI, VT100, VT52, or VTNT)
	CRLF            Send both CR and LF
	Microsoft Telnet>
	-----Original Message-----
	From: thalm []
	Sent: vrijdag 17 oktober 2003 14:56
	Subject: [Full-Disclosure] Strange netcat behavior
	Since netcat is a widely used network tool, this may have been discussed
	already, but since I wasn't able to found such discussion, here goes:
	When using netcat (Windows and Linux versions) to connect to a web server,
	and everytime ENTER is pressed in the command line, netcat only sends LF
	(0x0A) instead of CRLF (0x0D 0x0A).
	ex: GET / HTTP/1.0[LF][LF]
	when using telnet, the behavior is different:
	ex: GET / HTTP/1.0[CRLF][CRLF]
	Although webservers (IIS and probably Apache) don't mind such behavior and
	accept it (LF) as if it was CRLF, RFC 2616 clearly states that the HTTP
	Request/Response Line and HTTP Headers *MUST* be separated by a CRLF and not
	only by a LF.
	Why is there such a difference between netcat and telnet behavior?
	NOTE: I'm wondering if sometimes a webserver exploit works when HTTP "lines"
	are separated by [CRLF] and does not work when HTTP "lines" are separated
	only by [LF].
	This is actually the point I am refering to...
	Tiago Halm

Powered by blists - more mailing lists