Forum OpenACS Q&A: Bugtraq: Remote Compromise in Oracle 9i Database Server (and Oracle 8)

Date: Wed, 6 Feb 2002 06:33:56 -0000
From: NGSSoftware Insight Security Research 
Subject: Remote Compromise in Oracle 9i Database Server

NGSSoftware Insight Security Research Advisory

Name:    Oracle Remote Compromise
Systems Affected:  Oracle 9, 8
Platforms:  All Operating Systems
Severity:  High Risk
Vendor URL:
Author:   David Litchfield (
Date:   6th February 2002
Advisory number: #NISR06022002A
Advisory URL:

Attackers can execute any function in any library remotely on a system
running Oracle's database server without a user ID or password.

A large part of Oracle database functionality is provided by PL/SQL
packages. PL/SQL, or Procedural Language/ Structured Query Language,
SQL and allows an "executable" package be created that exports
and functions. PL/SQL packages can be extended to call functions
exported by
operating system libraries or Dynamic Link Libraries. It is possible
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
the name of a program to be executed. It is apparent that to do this a
must be able to connect to the Oracle database server and login with
account that has the CREATE LIBRARY permission before an attack
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.

When a PL/SQL package executing in the database is required to run an
external procedure the oracle process connects to the Listener and
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
into its own process address space but rather launches another
extproc on Unix systems or extproc.exe on Windows platforms, and
oracle to connect to it. Oracle obliges and connects to the extproc
using named pipes and makes the same request that it made to the
Extproc loads the library and calls the function. There is no
performed anywhere in all of this. This opens up a glaring and
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
problem is that, even though communication normally goes over named
it can be forced to use sockets and can be done remotely. Because of
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
would probably call system() exported by msvcrt.dll on Windows
platforms or
exec() or system() exported by libc on unix platforms. Any operating
command passed as a parameter to these functions would run in the
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,
local SYSTEM account. Needless to say that any commands executed as
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
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
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
many different names depending upon the system and Oracle version
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

If this functionality is required then it is possible to limit the
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"
requires a modification to the sqlnet.ora file found in the
etworkadmin directory. Add the entries

 tcp.validnode_checking = YES
 tcp.invited_nodes = (, scylla)

Replace or Scylla in this example with the hosts that require
access. Any host not listed here will still be able to make a TCP
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
listening on a non-default port (i.e. not 1521). Whilst this is not a
solution, as anyone with a TCP port scanner has a highly likely chance
finding the listener, it still helps.

Finally, on Windows NT/2000 the Oracle processes should not be running
local SYSTEM. It is suggested that a low privileged account be created
the Oracle processes run as this user. This account will need to be
the "Logon as a service" account privilege.

Oracle was alerted to the theoretical vulnerability last summer and
with working exploit code in October and are currently investigating
issue and working on a patch. NGSSoftware and Oracle have decided to
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
information is available from the NGSSoftware website,

Ugh ... so what pieces do we have that need EXTPROC?  Java's embedded within Oracle so I would think you don't (besides which we're ripping it out)?  We've also ripped out the Oracle smtp stuff.  Does InterMedia need this to run the INSO filters?

The firewall solution and the trusted IP solution both would pretty much seal one off from harm but just dumping EXTPROC altogether would be nicer, if we don't need it.

Can one of our more experienced Oracle types shed some light, here?

Ideally, this type of security stuff should be stuffed in our documentation at some point too.

"if you're not behind a firewall, here are steps you need to take to secure your Oracle installation. This is not a guarantee that your system will be secure, but it should help..."

I would phrase that

"if you're not behind a firewall, get behind a firewall.  Anyone purchasing
Oracle absolutely has the money to do that.  here are steps you need to take
to secure your Oracle installation against attacks on the internal network.
This is not a guarantee that your system will be secure, but it should help..."

Earlier versions of Oracle (8.1.6 and below?) run Intermedia through the extproc process.  Just make your listener listen on the loopback interface (localhost), or better yet use unix domain sockets.
AFAICT, 8.1.7 uses EXTPROC too, on Linux at least.  I haven't actually tried *not* using it, but it's created as usual by the Net8 assistant.
Stephen, could you post your listener.ora and tnsnames.ora config?
Just remove the line


from listener.ora, lsnrtcl stop, lsnrtcl start.

We've done that on most of our Oracle boxes now. The ones where we really need extproc,

/sbin/ipchains -A input 1 -s -j ACCEPT
/sbin/ipchains -A input 1 -s $LOCAL_IP_ADDRESS -j ACCEPT
/sbin/ipchains -A input 1 -d any/0 1521 -p tcp -j DENY
or equivalent in Solaris or router access lists.

Even on NT4 there is a primitive "port security" feature that can block 1521.

Should I take this part out too:
    (SID_DESC =
      (SID_NAME = PLSExtProc)
      (ORACLE_HOME = /ora8/m01/app/oracle/product/8.1.6)
      (PROGRAM = extproc)

Unfortunately, removing this line:
Seems to result in a
ORA-01034: ORACLE not available
Error. :(