Three Tier Oracle Security in London ~ Paul M. Wright

(nix, oracle, java, www, cloud ) intersect (safety, security, reliability, integrity)

Three Tier Oracle Security in London ~ Paul M. Wright RSS Feed

April 2010 CPU ~ Securing Java Applications at Design and in Production


So it is Oracle patch testing time again which includes Java and Applications too, not just the DB, but it’s a good place to start today…
The CPU or PSU is available for and above for most installations, though the next CPU is the last one for 9i. Most I think will be installing the PSU after an appropriate test period. I have just installed it and done a state check before and after to give a comparison which has been quite interesting.

The April PSUs installed fine on and for RHE 64bit

The install gotchas are this error message which seems to be ignorable.

The following warnings have occurred during OPatch execution:
1) OUI-67620:Interim patch 9352164 is a superset of the patch(es) [ 9119284 ] in the Oracle Home

and this one which needs opatch to be told where the inventory is

OPatch cannot find a valid oraInst.loc file to locate Central Inventory.
opatch apply -invPtrLoc /full/path/oraInst.loc

Apart from that, the install was pretty smooth. I did a state check of before and after the patch to provide a comparison of the changes made by the patch….

In summary the relevant results are :
DBMS_JVM_EXP_PERMS has public execute revoked and granted back to two roles:
Additionally DBMS_JVM_EXP_PERMS has a different checksum from the usual 1571791935 to 1575678292 so the code has changed..

SQL> select avg(dbms_utility.get_hash_value(text,1000000000,power(2,30))) 
from dba_source where name='DBMS_JVM_EXP_PERMS' and owner = 'SYS';


The other DBMS_JAVA and DBMS_JAVA_TEST package checksums have not changed and have been dealt with just by revoking public from oracle/aurora/util/Wrapper. Revoking public from DBMS_JAVA can not be done without affecting other Java applications hence this compromise. This is an incomplete solution because oracle/aurora/util/Wrapper is just a vector and if another utility class could be found or written then the escalation path becomes valid again in 11g..

More to come on Java Security at the ISSD Conference where I will be presenting on how to secure Three Tier Applications both by adopting secure coding and static/dynamic analysis within the initial development design phases, as well as how to use real-time application behaviour monitoring to scope incremental fixes to already installed applications that require high availability in Production. Application monitoring allows changes to be made with lower risk, more quickly, thus shortening the SDLC, and reducing costs. This two pronged approach is effective in commercial practice and I am excited to be able to present this to you at 10.15 AM on the 21st of May. I think the ISSD is a worthwhile cause so I am proud to support this initiative.

Look forward to seeing you there.


Leave a Reply

You must be logged in to post a comment.