mailing list archives
Some misc. info/recommendations on nmap crashing inetd
From: "Alek O. Komarnitsky (N-CSC)" <alek () ast lmco com>
Date: Wed, 19 Apr 2000 10:56:07 -0600 (MDT)
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.
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! ;-)
- Some misc. info/recommendations on nmap crashing inetd Alek O. Komarnitsky (N-CSC) (Apr 19)