Call: +44 (0)1904 557620 Call
Blog

Pete Finnigan's Oracle Security Weblog

This is the weblog for Pete Finnigan. Pete works in the area of Oracle security and he specialises in auditing Oracle databases for security issues. This weblog is aimed squarely at those interested in the security of their Oracle databases.

[Previous entry: "Oracle UK systems accused in 'SSH hacking spree'"] [Next entry: "First exploit released for CPU July 2007"]

CPU July 2007 is out



The latest quarterly security patch, the CPU July 2007 was out last night. It includes 45 fixes across all of the Oracle products. This differs to the pre-patch notice that stated there were 46 fixes in the patch. Alex talked about this in a post titled "Oracle CPU July 2007". Alex also pointed out in this post that a bug found by him, that is similar but not the same as the infamous Oracle 0-day bug - "Oracle has released details of a 0-day vulnerability including exploit code on Metalink" has finally been fixed. I hope that this is the last variant of this bug. Alex also talked about Eric Maurice's announcement in his blog of the new patch structure called a napply CPU. His blog post is titled "July 2007 Critical Patch Update Released" and he says:

"The napply CPU is an enhanced CPU format for Oracle Database Server for Unix and Linux platforms version 10.2.0.3 and onward (including 10.2.0.4 and 11g). In a napply CPU, the security fixes are now grouped in what are called molecules. Each molecule in the CPU is independent, and does not conflict with other molecules in the CPU. Conflicts between molecules occur when fixes included respectively in each molecule affect the same file or group of files."

and goes on to discuss

"By using the OPatch parameter ?-skip_duplicate?, customers will have the ability to skip the application of those molecules that have been previously installed (for example by a previous CPU) thus reducing the changes introduced to the patched system. In other words, while the CPU remains cumulative, the CPU will install incrementally those new groups of fixes."

I can see that this will help some sites install patches with less anxiety but I doubt that this will implore many sites to patch earlier and faster. The same fixes, cumulatively are still installed and still need to be installed. The biggest issue i discuss with people is the testing, the fact that often a full regression test is required and the worry that something in a fix breaks the way their applications work.

The best advice I offer is to ensure that you only install the software that is needed and remove as many features (schemas) and functionallity (Java?) that you dont need, in other words reduce the attack surface as much as possible to the functionallity actually needed to support an application. Also dont install Enterprise edition if you can run with Standard or Standard one. I often sites completely over specified in terms of database version/type and features installed.

There are 19 fixes for the database, interestingly one fix for Audit Vault (which is an Apex bug), 4 fixes for the application server, 2 fixes in JDeveloper, 1 collaboration Suite fix, 14 E-Business Suite fixes and 7 PeopleSoft fixes.

So, the observations last CPU that things were getting better could be wrong. This time we went to 45 fixes from 36 and 19 in the database as opposed to 14. Lets leave judgement till next time, this could be a blip in a downward trend or maybe its on its way up again, or maybe we have reached a plateau of around 35 to 45 fixes a patch?