Home    |    View Topics    |    Search    |    Contact Us    |   



Category:   Application (Firewall)  >   Gauntlet Vendors:   Secure Computing
Gauntlet Firewall 'sql-gw' Proxy Can Be Crashed By Remote Users Sending Invalid Data
SecurityTracker Alert ID:  1007799
SecurityTracker URL:
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  Sep 24 2003
Impact:   Denial of service via network
Exploit Included:  Yes  
Version(s): 6
Description:   A denial of service vulnerability was reported in the Gauntlet firewall. A remote user can cause the SQL-Gateway service to crash.

It is reported that a remote user can connect to the Oracle Proxy (SQL-Gateway) and send a series of invalid data to cause the sql-gw process to crash.

A demonstration exploit script is provided:

running sql-gw at the standard port 1521:

for a in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
telnet aaa.bbb.ccc.ddd 1521

According to the report, the vendor was notified in August 2003 but has been unable to reproduce the problem.

Impact:   A remote user can cause the sql-gw proxy to crash.
Solution:   No solution was available at the time of this entry. According to the report, the vendor has not been able to reproduce the problem.
Vendor URL: (Links to External Site)
Cause:   Exception handling error
Underlying OS:  UNIX (Solaris - SunOS)
Underlying OS Comments:  Tested on Solaris 8

Message History:   None.

 Source Message Contents

Subject:  [Full-Disclosure] Denial of Service against Gauntlet-Firewall / SQL-Gateway

DOS-Attack against Gauntlet Firewall
We found out a security-issue with the Oracle-Proxy (SQL-Gateway) of
Gauntlet Firewall, Version 6 (manufactured by Secure Computing/NAI,
serversrunning Solaris 8, newest Patches installed). 

Sending subsequent requests with invalid data to the firewalls SQL-gateway
results in an immediate crash. The firewall won't accept any further
connections on any SQL-gw that is defined in the rule base.
Secure Computing as vendor of Gauntlet could reproduce the DOS, patches or
bug fixes are not yet available.

We tried to monitor the firewall's sql-gw with our own monitoring-system to
make sure that we notice if it does not run. Some seconds later, the sql-gw
crashed and we were no longer able to connect the port.

Further investigation of the problem showed that the sql-gw-process can
easily be crashed on any Gauntlet-Firewall by simply connecting to it:

Try the following (_very_ basic) script, use your firewall's IP instead of
running sql-gw at the standard port 1521:

	for a in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
		telnet aaa.bbb.ccc.ddd 1521

You will see that the last try to connect (#17) results in "Connection
refused" and the process of "sql-gw" is no longer running on the firewall.
==> A DOS against Gauntlet is very easy.

This is especially unpleasant, as Gauntlet is one of the few major
firewall-products that provide true application level security _and_ do have
a dedicated application-proxy for SQL (sql-net 1 + 2). 
In fact, many companies use Gauntlet especially to protect database-servers.

Solution/ Patches:
Secure Computing (, the manufacturer of
Gauntlet-Firewall, has been informed by arago about the issue in August 2003
and has been able to reproduce the problem. 
Unfortunately, they have not yet managed to bring out a security-patch :-(
The only current solution they give is to use "plug-gws" instead of the
"sql-gws", which obviously weakens security _and_ performance a lot, as you
lose application-level security!   


Oliver Heinz + Thomas Neuderth

 | arago,                     |  Oliver Heinz                              |
 | Institut fuer komplexes    |  Bereichsleiter Systembetrieb & Security   |
 | Datenmanagement AG         |  eMail:                     |
 | Am Niddatal 3              |                                            |
 | 60488 Frankfurt am Main    |                      |
 | Tel: +49-69-40568-401      |  PGP-Fingerprint: a5de d4b4 46b3 4d8b 2646 |
 | Fax: +49-69-40568-111      |                   d4d0 e5fd d842 cc4e 7315 |

Full-Disclosure - We believe in it.


Go to the Top of This SecurityTracker Archive Page

Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2022, LLC