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
