The Oracle Global Product Security Blog

Hi, this is Eric Maurice again. Today, Oracle released the July 2009 Critical Patch Update (CPUJul2009).

This Critical Patch Update (CPU) includes 30 new fixes across hundreds of products, including some newly acquired product lines (including BEA).

This Critical Patch Update includes 10 additional fixes for Oracle Database Server. Three of these 10 vulnerabilities are remotely exploitable without authentication. None of these vulnerabilities affect client-only deployments.

Three of the Database Server vulnerabilities addresses in this CPU are particularly critical with CVSS Base Scores of 7.5 or over (“high severity” according to the NVD guidelines):
- Vulnerability CVE-2009-1020 receives a CVSS Base Score of 9.0 for Windows, and 6.5 for Unix, Linux, and other platforms. This means that a successful exploitation of the vulnerability can lead to a full compromise of the targeted server at the OS level only on Windows platforms. On other platforms, the scope of the exploitation will be limited to the database layer (i.e. only the database application will be compromised). This vulnerability affects Oracle Database Server 9.2.0.8, 9.2.0.8DV, 10.1.0.5, 10.2.0.4, and 11.1.0.7. —This vulnerability is not remotely exploitable without authentication: The attacker needs to be authenticated to the Database (or use a previously authenticated session) in order to carry on the attack.
- CVE-2009-1019 receives a CVSS Base Score of 7.5 denoting that a successful exploit of this vulnerability can lead to a full compromise of the targeted database. This vulnerability affects Oracle Database Server 9.2.0.8, 9.2.0.8DV, 10.1.0.5, 10.2.0.4, and 11.1.0.7. It is remotely exploitable without authentication.
- Finally, CVE-2009-1963 also receives a CVSS Base Score of 7.5; however it is not remotely exploitable without authentication, and only affects Oracle Database Server 11.1.0.6.

Oracle recommends that this Critical Patch Update be applied against affected Database Server as soon as possible. However, customers should be aware of mitigation measures that may decrease the risks posed by these vulnerabilities in unpatched systems. For example, database servers protected from the Internet through the use of reverse proxy and firewalls, and whose connections are limited to connections to a securely configured application server, are less vulnerable to external attacks. In addition, proper auditing and monitoring can mitigate the risks associated with attempts to exploit these vulnerabilities from an inside source. The security guides and checklists available on the Security Technology Center on Oracle Technology Network provide a number of recommendations to securely deploy Oracle products. When properly implemented, many of these recommendations will greatly reduce the risks posed by vulnerabilities addressed in CPUs.

In addition to the 10 Oracle Database Server fixes, this CPU also provides:
 two additional fixes for Oracle Secure Backup 10.2.0.3,
 two additional fixes for various versions of Oracle Application Server,
 five new fixes for various components of Oracle E-Business Suite,
 two additional fixes for Oracle Enterprise Manager 10.2.0.4,
 three additional fixes for various PeopleSoft components,
 one additional fix for Siebel Enterprise, and
 five additional fixes for the BEA products suite.

The Oracle Secure Backup vulnerabilities fixed in this CPU have respective CVSS Base Scores of 10.0 (CVE-2009-1977) and 9.0 (CVE-2009-1978). The last patchset affected by these vulnerabilities is Oracle Secure Backup 10.2.0.3. Oracle strongly recommends that all previous versions of Oracle Secure Backup be upgraded to version 10.2.0.3 and that the fixes be applied, or that customers apply a newer version (10.3.0.1.0). Of course, customers already running Oracle Secure Backup 10.3.0.1.0 or who are not running Oracle Secure Backup should not be concerned about the vulnerabilities associated with older releases.

Note that vulnerability CVE-2009-1094 listed in the BEA Risk Matrix section of the CPU advisory, and affecting the JRockit component, received a CVSS Base Score of 10.0. This fix was in fact released to address a number of vulnerabilities previously reported by Sun MicroSystems in a Security Alert released in March 2009. These multiple vulnerabilities affect the Sun Java Runtime Environment. Oracle CVE-2009-1094 refers to all the Sun advisories that were applicable to JRockit. The CVSS score of 10.0 reported by Oracle in today’s CPU advisory is the highest score (received from NVD) of all the advisories fixed in JRockit. Note that the CPU advisory provides the complete list of all the Sun advisories affecting JRockit.

For more information:

The Security Technology Center on OTN is located at http://www.oracle.com/technology/deploy/security/index.html

The July 2009 CPU advisory is located at http://www.oracle.com/technology/deploy/security/alerts.htm

Information to subscribe to Oracle security e-mail notifications is located on http://www.oracle.com/technology/deploy/security/securityemail.html

MetaLink Note 360870.1 (subscription required) explains the impact of Java security vulnerabilities on Oracle products.

MetaLink Note 394487.1 (subscription required) provides a detailed explanation on how the CVSS ratings are applied in the CPU documentation.

Hi, this is Eric Maurice again.

For the last three years, as we have released each Critical Patch Update (CPU), we have been simultaneously posting a summary of the CPU on this blog (see for example, the last blog entry discussing CPUJul2009). I was recently reviewing past blog entries and realized that one topic -- “How CPUs are tested by Oracle before their release” -- continues to be of great interest to customers, so I thought I’d discuss it here.

The topic of CPU testing by Oracle is relevant to customers because of the potentially significant impact of faulty patches. The most obvious impact of faulty patches is that they may fail to properly resolve the vulnerabilities they were intended to close. More importantly, faulty patches may cause regression issues resulting in data corruption, system outages or other effects that cause applications to execute improperly. (Regression issues occur when a change in the code results in introducing unexpected consequences such “breaking” a functionality that was present in previous versions of the code.) Ultimately, faulty patches almost always result in re-issuance by their author, and costly reapplication by customers. But perhaps the least desirable impact of faulty patches is that customers may delay or defer applying future patches because of a fear that “the security patches may create more problems than they solve.”

For all of these reasons, Critical Patch Update quality has been the highest priority for Oracle. Under the leadership of Mary Ann Davidson and her team, all parties involved in the production of Critical Patch Updates are told in no uncertain terms that faulty patches will not be tolerated.

So, how does Oracle help make sure that CPUs don’t create issues in customers’ environment? Let’s look at the process Oracle follows with Database Server CPUs, keeping in mind that Oracle’s objectives with CPU testing are twofold: (1) prevent undue consequences resulting from the CPU patches (regression issues), and (2) ensure that the vulnerabilities are addressed effectively (preventing incorrect or incomplete fixes).

The first step in the remediation process for any vulnerability is the discovery or reporting of the vulnerability to Oracle. Security vulnerabilities can be reported to Oracle by external sources such as customers and security researchers. Vulnerabilities can also (and often will) be reported by internal sources including: Oracle’s own assessment team, developers themselves, and results of automated tests used throughout development.

Once a vulnerability has been discovered or reported to Oracle, it is analyzed to understand -- for example -- what components or interfaces are affected, which components of the code are vulnerable, how the vulnerability can be exploited, how it can be eliminated, what other mitigation measures are possible, etc. (This analysis phase is so important and complex that it could be, by itself, a topic for a future blog entry.)

At the end of the analysis phase, a fix for the vulnerability is produced, and regression tests are conducted to verify that the fix will not result in unintended consequences. Developers and security experts then review this fix before being included in the main code line (that is, if the vulnerability is not limited to previous versions of the affected component) where full regression tests are run. Once the inclusion in the main code line is complete, the fix is ported to future patchsets. In addition, the fix can be scheduled for inclusion in a future Critical Patch Update.

Let’s now look at the process Oracle follows for testing Database Server security fixes specifically included in Critical Patch Updates. To understand the level of effort required with each CPU release, one has first to go back to understanding the scope of the Critical Patch Update program:
- CPU patches are released for ALL Oracle products every quarter, on the Tuesday closest to the 15th of the months of January, April, July, and October;
- On these dates, CPU patches are published for all supported versions on all their respective platforms (with the exception of On-Request versions)
- CPUs for many Oracle products are cumulative (i.e. CPUs include new fixes as well as previously-released fixes).
In other words, on the release day of the CPU, Oracle releases a large number of patch sets for each platform-version combinations affected by the CPU. For example, the April 2009 Critical Patch Update included fixes for seven versions of Oracle Database Server (11.1.0.6; 11.1.0.7; 10.2.0.3; 10.2.0.4; 10.1.0.5; 9.2.0.8; 9.2.0.8DV) on over 20 different platforms!

In order to provide enough time for thoroughly testing the fixes included in CPUs, the initial selection of the new fixes to be included in each CPU takes place 15 weeks before the CPU release date. These fixes are then backported to all supported version-platform combinations with a few exceptions for things like On-Request versions. Next, Oracle runs a full set of regression tests against the aggregated patches for each of these version-platform combinations.

Six weeks before the CPU release date, CPUs are assembled in what we call “early combinations.” These “early combinations” are provided to other development organizations to verify that CPU’s don’t create problems across the Oracle stack. For example, throughout this six weeks period, the development organizations for the various product lines such as E-Business Suite, PeopleSoft, and Siebel, perform tests with the database CPU early combinations to ensure that database fixes will not result in problems with the applications and to catch regressions that might occur with customer applications. During this period, Oracle performs additional comprehensive vulnerability fix testing to ensure that all newly addressed vulnerabilities are effectively fixed in all version-platform combinations of the CPU.

In addition to the steps above, during the four final weeks before the release of each CPU, CPU early combinations are provided to the support and other organizations to perform installation testing. It is during that period that Oracle ensures that documentation is clear and accurate and that the CPU installs as expected. It is also during this period that the support organization grows familiar with the CPU in order to provide support to customers who may call for CPU-related issues once the CPU has been published.

Note that under Oracle Software Security Assurance disclosure policies, Oracle doesn’t share CPU early combinations or other information associated to the upcoming CPU with third party organizations. This is because Oracle is very concerned about treating each customer equally, and ensuring that the content of the upcoming CPU not be leaked out, possibly aiding in the development of exploit code. However, during the entire process leading to the release of the CPU, Oracle works with the individuals who have submitted the vulnerabilities fixed in the CPU, keeping them informed of progress, and sometimes discussing the nature of the fix implemented by the CPU with them. These individuals, many of them security researchers, are listed in the credit section of the CPU Release Note.

This commitment to CPU quality under Oracle Software Security Assurance has eliminated many issues that customers may have previously encountered with Critical Patch Updates, leading a prominent security researcher to recently declare: “The database patches are very easy to apply and have very few problems. You get a huge benefit without a lot of effort.” This type of endorsement by folks in the security researchers and analysts’ communities, as well as positive feedback from customers, are great rewards for the people involved in the production, testing, and support of the Critical Patch Updates.