Oracle Remote Compromise
February 6th, 2002NGSSoftware Insight Security Research Advisory
Name: Oracle Remote Compromise
Systems Affected: Oracle 9, 8
Platforms: All Operating Systems
Severity: High Risk
Vendor URL: http://www.oracle.com/
Author: David Litchfield (david@nextgenss.com)
Date: 6th February 2002
Advisory number: #NISR06022002A
Advisory URL: http://www.nextgenss.com/advisories/oraplsextproc.txt
Issue
*****
Attackers can execute any function in any library remotely on a system running Oracle’s database server
without a user ID or password.
Description
***********
A large part of Oracle database functionality is provided by PL/SQL packages. PL/SQL, or Procedural
Language/ Structured Query Language, extends SQL and allows an “executable” package be created that
exports procedures and functions. PL/SQL packages can be extended to call functions exported
by operating system libraries or Dynamic Link Libraries. It is possible to create a (PL/SQL) library
and PL/SQL package that calls any function in any library on the file system. An attack would
probably call system() and pass the name of a program to be executed. It is apparent that to do this
a user must be able to connect to the Oracle database server and login with an account that has the CREATE
LIBRARY permission before an attack becomes successful. However, NGSSoftware Insight Security Research
has discovered a way to fool the Oracle database server into loading arbitrary libraries and executing
arbitrary functions without ever having to authenticate.
Details
*******
When a PL/SQL package executing in the database is required to run an external procedure the oracle
process connects to the Listener and requests that the Listener load the relevant library, call the function
and pass the function any parameters passed to it. The Listener does not load the library into its own process
address space but rather launches another process, extproc on Unix systems or extproc.exe on Windows platforms,
and directs oracle to connect to it. Oracle obliges and connects to the extproc process using named pipes and
makes the same request that it made to the listener. Extproc loads the library and calls the function. There is
no authentication performed anywhere in all of this. This opens up a glaring and extremely dangerous security hole.
It is possible for an attacker to masquerade as an Oracle process and execute any function in any DLL on the file
system. What exacerbates this problem is that, even though communication normally goes over named pipes, it
can be forced to use sockets and can be done remotely. Because of this, an attacker can write an exploit that
connects to the listener/extproc over TCP and, without ever having to authenticate, run any function in any library
they wish. A real world attack would probably call system() exported by msvcrt.dll on Windows platforms or exec()
or system() exported by libc on unix platforms. Any operating system command passed as a parameter to these functions
would run in the security context of the account running the oracle processes. On Unix systems this is commonly the
“oracle” user and on Windows NT/2000 this is, by default, the local SYSTEM account. Needless to say that any
commands executed as these users will have dire consequences for the computer system involved.
Fix Information
***************
There are several things that can be done to help mitigate the risk of such an attack. The first line of defense is,
of course, with the use of a firewall. No one should be able to access the listener port of 1521 from the Internet.
This not only helps mitigate the risk concerned with this problem but a slew of others, too.
Moving to the Oracle database server itself, PLSExtproc functionality can be removed if not needed. To do this
remove the relevant entries in tnsnames.ora and listener.ora. The PLS External Procedure service can have many
different names depending upon the system and Oracle version installed. This could be icache_extproc, PLSExtproc
or extproc. It is also suggested that extproc(.exe) be deleted, too, on the off chance that an attacker, replaces
the entries in tnsnames.ora and listener.ora.
If this functionality is required then it is possible to limit the machines that may access the listener.
Whilst this is a trust mechanism based only on IP address it does help. The process is called “valid node
checking” and requires a modification to the sqlnet.ora file found in the $ORACLE_HOME\network\admin
directory. Add the entries
tcp.validnode_checking = YES
tcp.invited_nodes = (10.1.1.2, scylla)
Replace 10.1.1.2 or Scylla in this example with the hosts that require access. Any host not listed here will still
be able to make a TCP connection to the listener but the listener will simply terminate the connection. Invited
nodes should be restricted to machines that require access.
As another step towards help mitigating the risk, you could set the listener listening on a non-default port
(i.e. not 1521). Whilst this is not a great solution, as anyone with a TCP port scanner has a highly likely
chance of finding the listener, it still helps.
Finally, on Windows NT/2000 the Oracle processes should not be running as local SYSTEM. It is suggested that a
low privileged account be created and the Oracle processes run as this user. This account will need to be given
the “Logon as a service” account privilege.
Oracle was alerted to the theoretical vulnerability last summer and provided with working exploit code in October
and are currently investigating the issue and working on a patch. NGSSoftware and Oracle have decided to release
this advisory in the interim of the patch becoming available so Oracle customers may take steps to mitigate the
risk that may be posed to their Oracle database servers.
A check for this security hole has been added to the Oracle scan module of Typhon II, NGSSoftware’s vulnerability
assessment scanner, of which more information is available from the NGSSoftware website, http://www.nextgenss.com/.
