This weekend I installed the new version of Oracle 18.104.22.168 (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 22.214.171.124 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:
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 126.96.36.199 Windows) ——————
— Check privs
— 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 188.8.131.52? 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 184.108.40.206 you should truncate the SYS.AUD$ table to avoid questions from (internal/external) auditors.