| VID |
25003 |
| Severity |
40 |
| Port |
1521, ... |
| Protocol |
TCP |
| Class |
DB |
| Detailed Description |
The PL/SQL package allows users who have the 'CREATE LIBRARY' privilege to call external functions in operating system libraries. To be able to call an external functions from within oracle a library must be created by a login account that has the CREATE LIBRARY privilege. By default the internal account, the sys, system, ctxsys logins can add libraries. If one of these logins or any other with the requisite permissions is compromised, an attacker can create a library and PL/SQL package that execute operating system commands in the security context of the operating system account running the oracle processes.
PL/SQL packages can be extended to call external functions in libraries or Dynamic Link Libraries. When a PL/SQL package in executing in the database server is required to run an external function 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 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 load 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's exacerbates this problem is that it can be done remotely and what's more over sockets. 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.
* References:
http://www.securityfocus.com/bid/4033 |
| Recommendation |
When Oracle is installed, a number of logins are created depending upon what components have been added each with a default password set. Invariably, but not always this password is the same as the user id. Third party add-on products to Oracle keep true to this model - they too often create a login with an easy to guess password. Every login should have its default password changed.
-- AND --
Filter incoming connections to the listener port of 1521.
-- OR --
Disable the PLExtproc functionality by removing relevant entries from the tnsnames.ora and listener.ora files. This function may have a variety of names, including icache_extproc, PLSExtproc and extproc.
-- OR --
It is possible to limit the machines allowed to connect to the listener process by adding the following entries to the file $ORACLE_HOME\network\admin\sqlnet.ora:
tcp.validnode_checking = YES
tcp.invited_nodes = (11.4.1.2, trusted_machine)
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. |
| Related URL |
(CVE) |
| Related URL |
(SecurityFocus) |
| Related URL |
(ISS) |
|
