Simplifying Hacks with the Oracle Data Pump Package
February 10, 2010
The latest Oracle vulnerability announcement at the Black Hat DC 2010 conference by security researcher, David Litchfield of NGS Software, could possibly prove troublesome for Oracle 11g users.
The potential impact of this set of vulnerabilities could be devastating to an enterprise that has sensitive data contained in databases, and allows low level privileged users access through a local or networked database session. To effectively exploit the vulnerabilities, the attackers will require some degree of SQL knowledge, but this knowledge should be relatively trivial to gain considering the Black Hat presentation currently available in the public domain.
The crux of the issues stem from the fact that Oracle seems to be in the business of enabling hackers instead of enabling business. Oracle provides the locked and loaded gun to would-be attackers in the form of the Oracle Data Pump maintenance and the Java virtual machine environment called Aurora.
To help their users with an upgrade, Oracle provides a suite of tools called the Oracle Data Pump which is installed by default. Contained within this tool is a package called DBMS_JVM_EXP_PERMS, which enables administrators to export permissions and to import them using a database procedure in that tool called IMPORT_JVM_PERMS. The procedure IMPORT_JVM_PERMS within the DBMS_JVM_EXP_PERMS package enables the administrator to provide it a list of permissions and update the Java policy table, where the security permissions for certain java actions are stored.
In order to allow Java code to read, write or execute files on the underlying server operating system, this Java policy table must have an entry.
Experienced security practitioners can already see the hand-writing form on the wall.
Oracle, as it should, does not give local users privileges to do read, write or execute files on the OS. However, there’s always a “however” in security, Oracle does allow by default ‘public’ role users to execute the DBMS_JVM_EXP_PERMS package.
What does this mean? This tool, provided by Oracle and installed by default with local user execute privileges, gives potential malicious users the ability to also perform the package procedure of IMPORT_JVM_PERMS and provide their own permissions to update the java policy table.
Mr. Litchfield continued to demonstrate how, by exploiting another Oracle provided Java class contained within Aurora, an attacker could eventually own the underlying OS to the extent of even creating his own user and granting them Administrator status on the server using the Oracle tool DBMS_JAVA.SET_OUTPUT_TO_JAVA.
DBMS_JAVA.SET_OUTPUT_TO_JAVA will redirect Java output to another java session. Per the specification for the SET_OUTPUT_TO_JAVA function, allows it to execute SQL when it receives the output. But Oracle, by default, has set DBMS_JAVA.SET_OUTPUT_TO_JAVA to execute with SYS user privileges, because the SYS user owns this package.
From this point it is just a matter of crafting a proper SQL query gives the package something to execute when the output is directed to another java session. The attacker then creates a query that causes Java to be output, which will in turn execute the SQL code that escalates the user to any role they wish, such as the ‘dba’ role.
It is recommended that all enterprises using Oracle 11g immediately remove the Data Pump tool packages mentioned, or change the permissions of the packages.
Additionally, this continues to underscore that an enterprise should consider an out of band DB monitoring solution, as once an attacker gains access to a database as the ‘dba’ role, you can no longer trust any logs that are output, or stored by the database server. Proper oversight will require an out of band solution that has complete visibility to view all database user network sessions.