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:
- cqure.net.20020412.bordermanager_36_mv1.a Patrik Karlsson (May 08)
- Re: cqure.net.20020412.bordermanager_36_mv1.a Corey J. Steele (May 10)
