Of zo:
Vulnerability in Oracle 9i Database Server Leads to Remote Compromise
------------------------------------------------------------------------
SUMMARY
Attackers can execute any function in any library remotely on a system
running Oracle's database server without a user ID or password.
DETAILS
Vulnerable systems:
Oracle version 9
Oracle version 8
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.
/u/26957/crop65e62184a4651_cropped.png?f=community)
:strip_icc():strip_exif()/u/30469/pyro2-60x60.jpg?f=community)