This weekend I installed the new version of Oracle 11.2.0.1 (64 bit) for Windows. The 11.2 version for Windows is available since a few days.
I installed the 64 bit version (default installation (next – next – …)) without any problems on Windows 7 system. After that I run a default check with our database scanner Repscan 3 (the most advanced database scanner) against this new database version. According to Repscan this new 11.2.0.1 is no longer vulnerable against the DBMS_JVM_EXP_PERMS exploit and this is correct. Oracle has already fixed the problem. I expect a solution in the upcoming Oracle CPU April 2010.
A quick check in the Repscan database browser shows the difference in the privileges:
11.2.0.1.0 Linux:
11.2.0.1.0 Windows:
Oracle removed the public privilege from DBMS_JVM_EXP_PERMS and granted privileges to the roles „IMP_FULL_DATABASE“ and „DATAPUMP_EXP_FULL_DATABASE“. The privileges of DBMS_JAVA and DBMS_JAVA_TEST are not modified.
The package DBMS_JVM_EXP_PERMS contains also a bug fix. A comparision between the Windows and Linux version shows the following differencein the package body.
— DBMS_JVM_EXP_PERMS (only in 11.2.0.1 Windows) ——————
[…]
— Check privs
sys.dbms_zhelp_ir.check_sys_priv(DBMS_ZHELP_IR.KZSSTA);
[…]
— DBMS_JVM_EXP_PERMS ——————
After that I analyzed the Oracle database with the Repscan database browser (really useful component, just try the trial version of Repscan) found a few suspicous audit entries in my audit log (sys.aud$).
A user AIME from the terminal „ST-ADC\DADVFH0169“ had a connection to my database?I know that the terminal „ST-ADC\DADVFH0169“ is a terminal somewhere from Oracle. A backdoor in 11.2.0.1? Someone from Oracle was accessing my database?
No. After I checked the timestamp I saw that this entry was created 2 days BEFORE I installed my database. Oracle only forgot to cleanup the audit log before delivering it to customers. If you install Oracle 11.2.0.1 you should truncate the SYS.AUD$ table to avoid questions from (internal/external) auditors.