I have confirmed it is also an issue with BorderManager 3.0 on NetWare 5d (I think it's service pack 4, don't remeber. :P). It replicates both the CPU usage and the high memory usage. I have also verified you don't need to keep the offending telnet session open to continue hosing the server. That NLM is part of the DNS/DHCP package. It's function is to log DNS and DHCP events from clients. Our solution was to simply firewall port 2000 from non-localhost traffic. Simple, easy, and effective. On Thu, 10 Feb 2000, Matthew Firth wrote: > The issue also affects BorderManager 3.0 (sp2) > running on NetWare 4.11 sp6a. I was able to > replicate the memory allocation error but have not > had any luck with obtaining the high CPU > utilisation. > > Again, csatpxy.nlm is loaded by default on this > system and unloading it stopped the memory > allocation errors. > > > matthew > > -----Original Message----- > From: Chicken Man [mailto:chicknmonat_private] > Sent: Wednesday, 9 February 2000 11:59 > Subject: Novell BorderManager 3.5 Remote Slow > Death > > > On a (default) installation of BorderManager 3.5 > sp1, spc02 running on > NetWare 5.0 sp3a with nici 1.3.1, telnet to port > 2000 on the firewall (on > either the public or private interfaces) and hit > enter a few times. > Utilization will jump (to 67% on our systems), and > the console will > immediately report an error similar to the > following: > > 1-27-2000 9:34:47 am: SERVER-5.0-830 > [nmID=2000A] > Short Term Memory Allocator is out of Memory. > 1 attempts to get more memory failed. > > The telnet session will not disconnect, unless you > manually close the > connection. Over the course of two days (every few > minutes or so, YMMV) the error will repeat, with > the number of attempts steadily increasing (by > several million each time). Eventually (again, for > us it was two days, YMMV) the firewall will deny > all requests, and eventually crash completely. > > Further symptoms: > > Using tcpcon you can see something listening on > port 2000. If the telnet > session has been closed from the remote end, > tcpcon reports that the > previous session is in a "closewait" state. It may > be possible to do more bad things since this entry > never clears automatically (i.e. use up the rest > of system resources by opening and closing > connections to this port). It can be cleared using > tcpcon. > > The misbehaving NLM is CSATPXY.NLM. It is the CS > Audit Trail Proxy, which is apparently loaded by > default on a BorderManager 3.5 install. From what > various people tell me, it could also be installed > on non-BorderManger Novell servers (though > probably not by default) which means this > vulnerability may extend beyond BorderManager 3.5. > > Novell was contacted regarding this and the answer > was "unload the NLM". > Unloading the NLM does stop the slow death. > Rebooting will reload the NLM so it must be taken > out of whatever loads it on boot, of course. > > <RANT> > Why is the port even accessable from the outside > (or the inside for that > matter)? The default BorderManager packet > filtering rules indictate that > pretty much everything is being passed. Why is the > NLM loaded by default? > Tcpcon shows various other services running that > shouldn't be either > (chargen, echo, etc). Why? What other > vulnerabilities am I missing? > </RANT> > > enjoy, > ChicknMon > > > > __________________________________________________ > ____ > Get Your Private, Free Email at > http://www.hotmail.com > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Michael R. Rudel =-= Computer Technician =-- Pinckney Community Schools Home: (734) 878-1504 Work: (810) 225-3995 Pager: (734) 651-4998 Co-Director, CU - TrekMUSH: ATS =-= E-Mail: mrrat_private =-= http://home.mrr.cx -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:34:05 PDT