Date: Tue, 22 Dec 1998 13:40:45 -0800 From: Lamont Granquist Reply-To: Bugtraq List To: BUGTRAQ@netspace.org Subject: Re: Nmap network auditing/exploring tool V. 2.00 released Another nmap-induced denial-of-service is against many machines inetd's when doing a TCP connect() scan (-sT) with the result of killing the inetd process. I've found that Digital Unix and Irix have been vulnerable to this. I cannot reliably reproduce the problem[*] and have not tested it against xinetd. The work-around for the nmap user is to never use connect() scans, and to explicitly use -sS (or one of the other stealth scans) in conjunction with -O. There is no workaround for the system admin of the scanned system that I know of, other than automated monitoring for crashed inetds (I'd probably use netcat connecting to an inetd service like TCP daytime in a loop with appropriate logic and an appropriate response action...). [*] I have confirmed that it happens in response to a connect() scan and not any other TCP scan type and that it sometimes occurs immediately following a connect() scan when the inetd had been verified immediately previously to be running fine. On Tue, 22 Dec 1998, Olaf Selke wrote: > According to Sherwood Botsford: > > > > On Tue, 15 Dec 1998, Fyodor wrote: > > > > = I have just released version 2.00 of nmap, a program for network > > = security auditing and general Internet exploration. Almost all of the > > = core code has been rewritten for better performance and accuracy, and > > = many new features have been added. Here are some of its current > > = capabilities: > > > > Hi. Any idea why most of my hosts running HPUX 10.10 crashed > > during a local network scan with > > nmap -O > > I reproducible crashed Cisco routers running IOS version 12.0(1) > with nmap -sU. > > Olaf > -- > Olaf Selke, olaf.selke@mediaways.net, voice +49 5241 80-7069 -- Lamont Granquist lamontg@raven.genome.washington.edu Dept. of Molecular Biotechnology (206)616-5735 fax: (206)685-7344 Box 352145 / University of Washington / Seattle, WA 98195 PGP pubkey: finger lamontg@raven.genome.washington.edu | pgp -fka -------------------------------------------------------------------------- Date: Tue, 22 Dec 1998 11:42:03 -0500 From: Jefferson Ogata Reply-To: Bugtraq List To: BUGTRAQ@netspace.org Subject: Re: Nmap network auditing/exploring tool V. 2.00 released Sherwood Botsford wrote: > > On Tue, 15 Dec 1998, Fyodor wrote: > > = I have just released version 2.00 of nmap, a program for network > = security auditing and general Internet exploration. Almost all of the > = core code has been rewritten for better performance and accuracy, and > = many new features have been added. Here are some of its current > = capabilities: > > Hi. Any idea why most of my hosts running HPUX 10.10 crashed > during a local network scan with > nmap -O This is a problem also on IRIX 6.5. The machine doesn't crash but inetd dies after one or two SYN scans. I talked to SGI about it and they recommended turning off the tcpmux and echo ports in /etc/inetd.conf, which indeed fixed the problem. The bug is fixed in IRIX 6.5.2, according to SGI, and I've been unable to kill inetd on an O2 running 6.5.2 using nmap. -- Jefferson Ogata National Oceanographic Data Center You can't step into the same river twice. -- Herakleitos -------------------------------------------------------------------------- Date: Wed, 23 Dec 1998 10:12:57 +0100 From: Casper Dik Reply-To: Bugtraq List To: BUGTRAQ@netspace.org Subject: Re: Nmap network auditing/exploring tool V. 2.00 released >Another nmap-induced denial-of-service is against many machines inetd's >when doing a TCP connect() scan (-sT) with the result of killing the inetd >process. I've found that Digital Unix and Irix have been vulnerable to >this. I cannot reliably reproduce the problem[*] and have not tested it >against xinetd. The TCP scan seems to be wide spread under inetd. It's caused by the inetd "internal" TCP services; when a connection is made and closed before a response can be send, inetd will die with SIGPIPE. This affects the services that do not fork() prior to running; discard, echo and chargen do fork(), I believe, but time and daytime only send a single respone and fork()ing wasn't deemed necessary. It does affect Solaris prior to Solaris 7 (where it was fixed before it was understood how easy it was to trigger) Casper