Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> Remote Compromise in Oracle 8i/9i Database Server

Remote Compromise in Oracle 8i/9i Database Server

From: Orr, Steve <sorr_at_rightnow.com>
Date: Wed, 06 Feb 2002 10:46:13 -0800
Message-ID: <F001.004078B9.20020206091326@fatcity.com> 






Take a look at this...



-----Original Message-----


Sent: Tuesday, February 05, 2002 11:34 PM
To: bugtraq_at_securityfocus.com



NGSSoftware 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_at_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/.












-- 



Please see the official ORACLE-L FAQ: http://www.orafaq.com


-- 



Author: Orr, Steve


  INET: sorr_at_rightnow.com


Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------


To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
Received on Wed Feb 06 2002 - 12:46:13 CST












Original text of this message













  HOME |
  ASK QUESTION |
  ADD INFO |
  SEARCH |
  E-MAIL US