Bugtraq mailing list archives

Re: cqure.net.20020412.bordermanager_36_mv1.a


From: "Corey J. Steele" <csteele () good-sam com>
Date: 10 May 2002 13:05:26 -0500

On Wed, 2002-05-08 at 05:03, Patrik Karlsson wrote:
cqure.net Security Vulnerability Report
No: cqure.net.20020412.bordermanager_36_mv1.a
==============================================

Vulnerability Summary
---------------------
Problem:           Multiple vulnerabilities identified in
                   Novell Border Manager 3.6. During our brief
                   look at Novell Border Manager 3.6, we have
                   identified three issues within the product.
                   The vulnerabilities will cause the handling
                   NLM to abend, and in some cases result in a
                   DOS of the Novell server.

Threat:            An attacker could prevent legitimate use of
                   the Novell server, by sending special crafted
                   information to the server.

Affected Software: Border Manager 3.6 SP 1a.

Platform:          Netware 6.0 SP 1 verified.


Vulnerability Description
-------------------------
The first vulnerability is within the FTP-proxy server of BM 3.6.
After issuing the connection request to the proxy an attacker could
send a couple of megs of random data, which would cause the server
to stop responding to tcp/ip for a while. The server will then start
answering tcp/ip traffic again after 10 to 20 seconds. If this is
repeated for ten times or so, our test environment stop responding
to tcp/ip alltogether, and the server had to be rebooted to regain
full functionability.

The second vulnerability is in the ip/ipx gateway on tcp port 8225.
If one would send approximately two megabytes of random data to this
port, the nlm ipipxgw.nlm will abend.

The third vulnerability is in the RTSP proxy running on port 9090.
One could cause the proxy.nlm to abend by simply connecting to the
port, issuing the command "GET" followed by six enters.
<snip>


Additionally, Border Manager (I think 3.5) was/is vulnerable to a
connection table DoS... 

Several months ago, we had a BM 3.5 box setup to PAT (port-address
translate) our private address space (RFC1918 compliant) out to a single
external IP address.  We did not use all of our alloted private spacing
(we used a 255.224.0.0 netmask instead of the available 255.0.0.0).  

When I first began working with my employer, I did not take in to
account our limited network masking and began to scan the network with a
netmask of 255.0.0.0 (mea culpa!)  The BM was configured to route
anything it did not have a known route to out its public interface. 
Because the BM did not know routes to roughly 15 million address I was
scanning, it tried to build connections out on the public interface to
those hosts... The result was to fill up the BM's connection tables and
thus prevent further connections from being built.

I seriously doubt that this is a symptom of PATing firewalls as a whole,
so I am left believing this is a BM specific issue.  Can anyone comment
on this?

Note: I have since taken the BM out of production, and no longer have
access to it for testing purposes.

-C
-- 
Information Security Analyst
Good Samaritan Society
e-mail: csteele () good-sam com
voice: (605) 362-3899
PGP Key fingerprint = 564F 2A97 2ADA F492 F34C  8E4A 12AF 9DC3 400E 2DD6

Current thread: