Application Security, Inc.
home client login partner login online store contact us
search:
Solutions Products Partners Support News & Events About Us

Team SHATTER Security Alert

SERVICE_NAME remote buffer overflow in listener

June 13, 2002

To determine if you are vulnerable to this attack, download AppDetective for Oracle from http://www.appsecinc.com/products/appdetective/oracle/

Risk level: High

Summary:

A buffer overflow attack exists in the Oracle listener service that allows an anonymous user to execute arbitrary commands by sending a long SERVICE_NAME in the connection string.

Systems Affected:

Oracle9i on Windows and VM

Details:

A buffer overflow exists that allows an anonymous attacker to execute arbitrary shell commands under the security context of the listener service. In the first packet sent to an Oracle listener, a connection string is sent which describes the database to which to connect and includes optional commands. Within the connection string is a field called SERVICE_NAME. When the SERVICE_NAME is 8000 bytes or longer, a buffer overflow occurs in the listener service.

Below is an example of a connection string: DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.1.100)(PORT=1521))(CONN ECT_DATA=(SERVICE_NAME=appsecinc.com)(CID=(PROGRAM=C:\Oracle\SQLPLUSW.EX E) )

When the long SERVICE_NAME is sent to the listener, the following entry will appear in the listener log file: 12-JUN-2002 19:02:24 * 12502 TNS-12502: TNS:listener received no CONNECT_DATA from client

When forming the error message written to the listener log file, the stack is overwritten causing the buffer overflow.

This attack does not crash the listener. This attack can be mounted by any remote users that can send packets to the IP address and port of the listener.

The listener:

- is a server-side program that manages connecting clients to the database

- handles the connection request from a client to a database

- first accepts the connection and then negotiates with the database to setup a channel between the two ends

- returns the connection information to the client allowing the client and database to establish a connection

The listener typically runs under the following privileges:

- Using the oracle software owner account on UNIX

- Using the LocalSystem account on Windows

Because the listener has such a high level of privileges, any actions this process can take should be restricted.

For more details on this issue, go to http://otn.oracle.com/deploy/security/pdf/net9_dos_alert.pdf

Fix:

This vulnerability occurs for all versions of Oracle running Windows prior to Oracle9i release 2. A patch is available for Oracle 9.0.1 (patch number 1859604) on Windows.

This problem can also be solved by upgrading the listener to Oracle9i Release 2. Installing or upgrading only needs to be done on the listener, not necessarily on the database.

An alternate solution to reducing the likelihood of this attack is to restrict the IP addresses that are allowed to connect to the listener. This can be controlled by setting the validnode_checking parameter in the protocol.ora file to restrict access to an Oracle database based on network address. The protocol.ora file is located in $ORACLE_HOME/network/admin on UNIX and ORACLE_HOME\network\admin on Windows platforms, or in the directory specified by the TNS_ADMIN environment variable or registry value.

tcp.validnode_checking = YES

tcp.invited_nodes= (webserver.appsecinc.com, 192.168.1.110)

tcp.excluded_nodes= (attackers.com, 144.25.5.25, 234.12.3.12)

The first line enables this features. The invited nodes is a list of the hosts, either DNS name or IP address, that are allowed to connect. The excluded nodes is a list of hosts that are not allowed to connect to the database.

Note that the tcp.invited_nodes parameter takes precedence over the tcp.excluded_nodes parameter if both lists are present.

This solution is still not perfect since you can not include a list of all the addresses that should not access your database, and maintaining the list of allowed users would involve a significant amount of administrative work. Also note that spoofing IP addresses, which is very possible although does require some hacking skills, makes this security feature unreliable. If you must use this solution, it is recommended that your database be behind a firewall.