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
Again, csatpxy.nlm is loaded by default on this
system and unloading it stopped the memory
From: Chicken Man [mailto:chicknmon () HOTMAIL COM]
Sent: Wednesday, 9 February 2000 11:59
Subject: Novell BorderManager 3.5 Remote Slow
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
1-27-2000 9:34:47 am: SERVER-5.0-830
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.
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
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?
Get Your Private, Free Email at
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