lists.openwall.net   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  linux-cve-announce  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]
Message-ID: <2305CFC39C15AA4896E06E5C91C509EF0381B1F7@VS2.hdi.tvcabo>
From: thalm at netcabo.pt (thalm)
Subject: 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
http://www.kodeit.org


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ