Some misc. info/recommendations on nmap crashing inetd

["Alek O. Komarnitsky (N-CSC)" <alek () ast lmco com>]

There was some discussion a few weeks back about nmap crashing inetd.

This should NOT happen ... since inetd and/or TCP/IP stacks should not
be this fragile/weak ... but the reality is we have to deal with what 
is out there in the "real" world ... and users/admins sometimes "bark"
when we say that the actual problem is they need to fix their machines.

Attached is a snippet of something I wrote up internally that may
be of interest to folks on this topic.

alek


P.S. I've had about 150 folks download the latest version of nmap-web;
which is a quick-n-dirty Perl/CGI Web interface to nmap. I added a few
sentance in the INSTALL documentation to make it a little clearer how
the 6 steps (one is installing nmap and one is using it!  ;-) work.
A tarball/screenshots can be found at:
    http://www.komar.org/komar/alek/  ->  Misc. Tech Stuff  ->  nmap-web



---------------- SNIPPET --------------------------------

When run Site-wide (1,000+ machines), a few machines would randomly
exhibit inetd "hangs/stalls" ... this was VERY random ... and was typically
complicated by the fact that there are always a handful of machines that
are down, semi-broke, out-of-date WRT patches, mis-configured, etc.

BTW, rest assured I was NOT happy with hanging up machines ... I'd hope
that goes without saying.

However, I was able to isolate/repeat the behavior (still random and still
affected just a few percent of machines) and I might have it semi-figured out.
Note that this is basically a remote Denial of Service (DoS) because we
have a bug and/or "weak" TCP/IP stack/inetd executeable ... and we should
REALLY want to fix this on our machines since anybody could do it.

- HP: This would crop up on a handful of HP's UNTIL patch PHNE_16832
was installed which specifically addresses an inetd DOS. I absolutely
pounded the crap out of 50 HP's that were correctly patched and could
never duplicate the problem of inetd hanging. The only other times I
have seen it on HP's is when this patch is not installed (I've tried
to make sure this is installed Site-wide) and/or an ancient OS such as
snt-view which is running HP-UX9.07!   ;-)


- SUN: I'm able to duplicate this problem when scanning a large number
of SUN machines - typically a few percent will be DOS'ed. Sun BugID #4169474
discussed an issue with "xaudio/Xaserver" ... and we have applied the fix
to that (comment out an incorrect inetd.conf entry). However, SUN machines
still appear vulnerable to this problem ... so I spent a fair amount of time
looking through the SunSolve Database (keyword=inetd didn't find this!)

Sun BugID #4297716 references a problem very similar to ours for Solaris2.6.
I think the solution here is to upgrade 105181 from the current patch rev-16
that is installed Site-wide to rev-20 (latest release).  For Solaris5.7, I'd 
suggest upgrading 106541 from the current rev-07 to rev-10 (latest release).

NOTE: I THINK these would address the issue, but I did not actually TEST
this by applying the patch to a bunch of machines and trying it ... since
there are some "political" issues that need to be addressed. 


- SGI: I'm able to duplicate the problem there, but the SGI Web Site is
a bit confusing to me, nor do I have "login" access to the patch stuff
and I didn't see anything on the publically available stuff ... but my
bet would be that there is something out there ... hopefully!   ;-)