Bugtraq mailing list archives
Re: Novell BorderManager 3.5 Remote Slow Death
From: mrr () BRIG PCS K12 MI US (Michael R. Rudel)
Date: Wed, 9 Feb 2000 16:00:41 -0500
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:chicknmon () HOTMAIL COM] 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: mrr () mrr cx =-= http://home.mrr.cx -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Current thread:
- Re: Novell BorderManager 3.5 Remote Slow Death Matthew Firth (Feb 09)
- Re: Novell BorderManager 3.5 Remote Slow Death Michael R. Rudel (Feb 09)
- <Possible follow-ups>
- Re: Novell BorderManager 3.5 Remote Slow Death Kevin Novak (Feb 21)