COMMAND
BorderManager
SYSTEMS AFFECTED
Novell BorderManager 3.5
PROBLEM
'Chicken Man' found following. 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.
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.
Same happens with several servers running NetWare 5.0 sp4 and
BorderManager 3.0 (Enterprise Edition).
SOLUTION
BM 3.5 sp1 was checked out and there are still issues, but we'll
get into that. Port 2000 is used by CSATPXY, which as we
understand it is used by the DNS/DHCP management console to view
the audit logs. If you telnet to port 2000 and/or pump a lot of
garbage to it, the server eventually pukes. Odd, but whatever...
(An official Novell explanation for what CSATPXY.NLM actually does
is documented in Novell TID# 2953101. This document explains why
the port is left in a listen state, and explains how to have the
NLM listen on another port, however, all attempts to assign to a
different port on my test server failed; it always resorted to
port 2000.) Ok, so put to put this thing to rest you have to:
-apply NetWare 5.0 SP4a
-apply Border Manager patch (in our case 3.0 SP 2, for 3.5 it's SP 1)
-apply CSATPXY2.EXE (Novell TID 2955744)
-and for those that really want to be safe: go in, blow away
the default filter rule sets (use filtcfg) and blow away any
rules allowing external access to port 2000. *THIS IS
ENABLED BY DEFAULT* IOHO, this is the safest bet because lord
know what other unknown goodies Novell provides with this
CSTPXY thing.