The Oracle® Hacker's Handbook: Hacking and Defending Oracle

3.1. Attacking the TNS Listener

The TNS Listener before 10g could be remotely administered out of the box without having to supply a password. Because the location of log files and trace files could be specified, it was possible for an attacker to set the log file to, for example, a batch file in the administrators startup folder on Windows, or the .rhosts file in the Oracle user's home directory on *nix. Once it was set, the attacker could then send a command to run or "+ +" in the case on *nix and have those commands execute or be able to use the r* services to run commands as the Oracle user. As well as being able to set a password to administer the Listener, Oracle added another option to the Listener —namely, ADMIN_RESTRICTIONS. When enabled, certain commands, such as changing the location of the log files, could only be executed locally. This is discussed fully at www.jammed.com/~jwa/hacks/security/tnscmd/tnscmd-doc.html.

In addition to this, the TNS Listener has suffered from a number of buffer overflow vulnerabilities in the past. For example, in June 2002, Oracle fixed an overflow in 9i where an overly long service_name parameter would trigger the issue.

(DESCRIPTION=(ADDRESS=
(PROTOCOL=TCP)(HOST=192.168.0.65)
(PORT=1521))(CONNECT_DATA=
(SERVICE_NAME=shellcode_goes_here)
(CID=
(PROGRAM=SQLPLUS.EXE)
(HOST=foo)(USER=bar))))

The error occurs because the user-supplied service_name is copied to a stack-based buffer when writing an error to the log file. An attacker could exploit ...