December 26, 2004 Hat-Squad Advisory: Remote buffer overflow in Netcat TCP/IP Swiss Army Knife Product: Netcat - nc11nt.zip Vendor Url: http://www.securityfocus.com/tools/139/scoreit Version: Netcat v1.1 Vulnerability: Remote stack overflow in the DNS control part Release Date: 26 December, 2004 Vendor Status: Informed on 10 November 2004 Response: 11 November 2004 No fix Overview: The program 'netcat' is an advanced form of the Telnet command when used in a hackers hands. Netcat is a simple Unix utility which reads and writes data across network connections, using TCP or UDP protocol. It is designed to be a reliable "back-end" tool that can be used directly or easily driven by other programs and scripts. At the same time, it can also be used as a network debugging and exploration tool, since it can create almost any kind of connection you would need and has several interesting built-in capabilities. Standard input is normally sent to the host, and anything that comes back across the connection is sent to standard output. This continues indefinitely, until the network side of the connection shuts down. Netcat can also function as a server, by listening for inbound connections on arbitrary ports and then doing the same reading and writing. Problem: 1. Stack based Buffer Overflow: Due to a boundary check bug in the DNS part, sending a client command with more than 256 bytes will cause a stack buffer overflow. This vulnerability can compromise several tools working without port listener as the the set of tools "uw-imapd" (www.washington.edu/imap/), loaded with netcat , this is tested wulnerable. Read the PoC code if you need more informations on this vulnerability. Discovery and Proof Of Concept Exploit by class101 (class101hat-squad.com) Greetings to Nima Majidi and Behrang Fouladi! -=Hat-Squad.com=- ---------------------- /* Netcat v1.1, "-e" Switch, Remote Buffer Overflow Exploit v0.1 Homepage..........: http://www.securityfocus.com/tools/139/scoreit Affected versions.: v1.1 Fix...............: Actually none, Hobbit is warned 1 month+ ago, and looks like to not act, we let him to spread a backdoor :) Risk..............: Highly critical. -Almost everything loaded as "nc ... -e ..." is vulnerable -Educational tools such as the uw-imapd (http://www.washington.edu/imap/) contains no port listener, if it's loaded with netcat (ie: nc -L -p 143 -t -e imapd.exe 25 -t -e pop3d.exe etc..vulnerable..) this small example show you the large impact of this hole. -Tools build on netcat , I guess are vulnerable , such as the netcat with authentification or others tools based on netcat without a security check on src. -Next time you run netcat -e , be sure of what you run because as said Hobbit, the "-e" switch is really DANGEROUS!! :DDD Compilation.......: 101_ncat.cpp ......... Win32 (MSVC,cygwin) 101_ncat.c ........... Linux (FreeBSD,etc..)
Removed the proof-of-concept and gR33tZ from description. See URL for more information. vapier, please verify/advise.
the description: > Due to a boundary check bug in the DNS part, sending a client command with > more than 256 bytes will cause a stack buffer overflow. This vulnerability > can compromise several tools working without port listener as the the set of > tools "uw-imapd" (www.washington.edu/imap/), loaded with netcat, this is > tested wulnerable. this implies that netcat parses the input sent to it via remote connections and thus a remote user can somehow smash netcat's stack ... when in listening mode, netcat never read()'s an incoming socket in the case of using -e (which is not available in Gentoo builds unless a user emerges with USE=GAPING_SECURITY_HOLE), netcat simply sets up std{in,out,err} exactly like inetd does before running execl(program passed via -e) that means, if there's any buffer overflow here, it's with the programs that netcat executes ... and really, who the hell uses netcat for their inetd ;) ... netcat is a quick & dirty tool to test stuff with, it isnt for real services not quite sure where this '256 byte buffer' they describe comes into play ... in the dns handling function gethostpoop(), a static 256 byte buffer is utilized, but the memory that is copied into it is from the gethostname() function, and it is copied with strncpy with proper length checks anyone else feel like verifying this ? the overall tone of the release info is pretty amateurish, so i'm not putting too much faith in it
It looks bogus. In fact I don't care about it since only those who compile with GAPING_SECURITY_HOLE may be affected. I suspect this only affects the old win32 build at securityfocus. Closing as INVALID since -e is not supported here. Reopen if you have more information...
