[13790] in bugtraq
Re: Novell BorderManager 3.5 Remote Slow Death
daemon@ATHENA.MIT.EDU (Michael R. Rudel)
Thu Feb 10 14:48:20 2000
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-Id: <Pine.BSF.4.21.0002091557180.53772-100000@brig.pcs.k12.mi.us>
Date: Wed, 9 Feb 2000 16:00:41 -0500
Reply-To: "Michael R. Rudel" <mrr@BRIG.PCS.K12.MI.US>
From: "Michael R. Rudel" <mrr@BRIG.PCS.K12.MI.US>
X-To: Matthew Firth <matthew.firth@MATERA.NET.AU>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <002201bf730f$bbfa25e0$8c5025cb@corp.matera.net.au>
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
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
