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. 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? enjoy, ChicknMon __________________________________________________ ____ Get Your Private, Free Email at http://www.hotmail.com