Re: DOS on inetd w/ nmap

[rdump () RIVER COM (Richard Johnson)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

At 07:45 -0600 on 4/24/00, Clifford, Shawn A wrote:
> Hi All,
>
> The problem is that inetd will abort when too many connections are made.
> This is an old problem that appears to still be a problem even on some newer
> OSes, specifically IRIX (*all* 6.2-6.5, others?), some HP-UX (B.10.20, but
> only on some machines... dunno why), and of course old SunOS 4.1.3/4.1.4
> machines (only some!).  You must then log on at the console (unless you had
> a remote window open to the machine prior to inetd exiting) and either
> restard inetd or reboot the machine.

On IRIX, inetd is croaking because it has problems with its built-in support
for small services.  Turning those off (specifically echo, tcpmux) in
inetc.conf was the solution SGI suggested for keeping inetd running on an O2K.
 This is reportedly fixed in IRIX 6.5.2, but I don't have bug ID or patch ID
info.

This was reportedly fixed as well in Solaris 7 or 8.  It is most likely bug
4154509 / 4154391.

I suspect that the bug causing inetd to die silently or go deaf is in supplied
SysV code, as inetd seems to stop listening on multiple SysVish OSes (IRIX,
Solaris, HP/UX, DG/UX, etc.) for similar reasons.  This may be related to
inetd on all those systems having a low hard-coded number of listeners (around
10).

Also on Solaris, Alek Komarnitsky mentioned Capar Dik's post to bugtraq(?)
which gave some details on another problem discovered by David Brumley that
would panic the OS.  This is Solaris bug ID 4178455.  See
<http://www.securityfocus.com/vdb/bottom.html?vid=655>.

The recursive_mutex_enter problem doesn't necessarily involve inetd.  It
appears to be a separate issue for OSes using streams when one of their open
ports is hit with nmap -O.  I suspect, based on half-remembered bugtraq posts,
that if inetd is the listener on the IDed port it might not panic the OS until
it is HUPped sometime later.

> /var/adm/SYSLOG entry:
> Apr   5 18:30:43 3D:node famd: fd 10 message length 1212498244 bytes exceeds
> max of 1064.

Hmm, I haven't seen that message length report before.

sgi_fam is probably the "file alteration monitor".  In IRIX < 6.5, it gave out
directory listings to any remote visitor who tickled it right.

> What's doubly annoying about this is that nmap is such a good tool,
> otherwise, and is being promoted by SANS as a tool of choice.  Clearly
> crashing inetd isn't very subtle.  Perhaps there is a way to make nmap
> "low-and-slow"?

'nmap ... -T Polite ...' avoids overloading ip-filter's state table on my scan
source boxes that are using 'pass out... keep state' to open up for return
traffic.  It may help to avoid inetd problems on the targets as well.

You could go the other way, too.  There were reports at SANS NS 99 in New
Orleans about 'nmap ... -T Insane ...' piped through a fragrouter causing
certain commercial all-in-one firewall boxes to fail open.

Richard

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.2
Comment: www.europarl.eu.int/dg4/stoa/en/publi/166499/execsum.htm

iQA/AwUBOQXEEGKSuJuuNAZUEQIvxgCgti+2ivXXoHTz5sYu7mwzHKeMEx4AoK9u
+h0UBH0uy/PXnzNbuNTyAnQR
=OO64
-----END PGP SIGNATURE-----