Hello, this is Eric Maurice.

Oracle released the April 2011 Critical Patch Update (CPUApr2011) today. As a reminder, note that security fixes for Java SE and Java for Business continue to be released on a separate schedule as the "normal" Critical Patch Update because of commitments made to customers prior to Oracle's acquisition of Sun. The next release date for the Java SE and Java for Business Critical Patch Update is June 7th 2011.

Today's Critical Patch Update provides fixes for 73 new vulnerabilities across a large number of product families including: Oracle Database Server, Oracle Fusion Middleware, Oracle Enterprise Manager Grid Control, Oracle E-Business Suite and Supply Chain Products Suite, Oracle PeopleSoft Enterprise, and Oracle JDEdwards EntepriseOne, Oracle Siebel CRM, Oracle Industry Applications, Oracle Sun products suite, and Oracle OpenOffice Suite.

The most severe vulnerabilities addressed in this Critical Patch Update have received a CVSS Base Score of 10.0. The first CVSS 10.0 vulnerability affects Oracle JRockit, and refers to a vulnerability (CVE-2010-4452) that was previously addressed with the February 2011 Critical Patch Update for Java SE and Java for Business. The second vulnerability affects Oracle Sun GlassFish Enteprise Server / Sun Java Systems Application Server.

Among these 73 new fixes, Oracle Database Server receives 6 new fixes, including 2 fixes for Oracle Database Vault (each with a CVSS Base Score of 3.6). In addition, 3 non-database fixes are also applicable to Oracle Database Server deployments: these are for vulnerabilities affecting Oracle Enterprise Manager Grid Control and Oracle Fusion Middleware. The highest CVSS Base Score for these Database Server vulnerabilities is 6.5. Note that we recently published a blog entry explaining Oracle's application of the CVSS standard.

18 out of the 73 fixes in this Critical Patch Update are for the Oracle Sun products suite, and an additional 8 are for Oracle OpenOffice. The highest CVSS Base Score for vulnerabilities affecting the Oracle Sun products suite is 10.0. The highest CVSS Base Score for vulnerabilities affecting the Oracle OpenOffice Suite is 9.3.

In recent years, I have often been asked to describe the Oracle organization that produces the security fixes included in the Critical Patch Updates. Today's Critical Patch Update provides a good opportunity to discuss this aspect of the program. A key aspect of Oracle's security model is that it is largely decentralized.

A core product security group under Oracle's Chief Security Officer, Mary Ann Davidson, is responsible for managing the security programs, ensuring compliance with Oracle Secure Coding Standards across development organizations, and managing internal (ethical hacking) and external (Common Criteria, FIPS) security assessments.

Each development team is responsible for the production of the security fixes for their specific products. However, the responsibility of ensuring the effectiveness of the fix is shared across organizations: the Oracle Software Security Assurance team makes sure that the fix provides effective remediation and that, potentially, all other related bugs are addressed as well. Other development teams will test the fix to ensure that it doesn't introduce regressions with their products (i.e. we test our fixes to ensure that each product across the stack continues to perform as expected). Technical Support also tests the fixes, and will also ensure that the documentation for the fix is accurate, etc. For more information, a detailed description of Oracle's practices for the testing of Critical Patch Update fixes is included in the white paper "Recommendations for leveraging the Critical Patch Update & maintaining a proper security posture" available on the Oracle Software Security Assurance web site.

This decentralized approach has several benefits. Code ownership is maintained and, as a result, development organizations quickly gain from the knowledge of past mistakes. Furthermore, Oracle's product portfolio is very diverse, and from a security perspective, it is important to retain some level of specialization: the concerns of web application developers may not be altogether the same as the ones of OS developers (e.g. focus on cross site scripting and SQL injections, as opposed to buffer overflows). Finally, another great benefit of this approach is that no single organization can be a bottleneck for the timely production of security fixes. As a result, the Critical Patch Update program, with some customization (e.g. separate schedule for the security fixes for Java SE and Java for Business), was able to adapt to the inclusion of additional product lines over the years.

For More Information:
The Critical Patch Updates and Security Alerts page is located at http://www.oracle.com/technetwork/topics/security/alerts-086861.html
More information on Oracle Software Security Assurance is located at http://www.oracle.com/us/support/assurance/index.html

Hi, this is Eric Maurice again!

A few years back, I wrote a series of blog entries discussing Oracle's application of the Common Vulnerability Scoring System (CVSS). However, shortly after the publication of the January 2011 Critical Patch Update, I saw a number of inaccurate claims made about Oracle's application of the CVSS standard. In this blog, I will attempt to explain how CVSS Base Scores are computed by Oracle, and highlight the limitations of the CVSS standard as it now exists (version 2.0).

In a nutshell, CVSS is an open standard designed to allow organizations to understand the criticality of security vulnerabilities and assess the priority given to security patching. It is platform and technology independent; in practice, CVSS scores can be used to rate security vulnerabilities (to get an indication of their relative severity) affecting a very wide range of software products: operating systems, web and legacy applications, security products (firewalls, antivirus software, etc.), databases, etc.

An overall CVSS Score is actually composed of 3 sub-scores (the "Metric Groups"): the Base Score, the Temporal Score, and the Environmental Score. The CVSS' "Complete Guide to the Common Vulnerability Scoring System Version 2.0" provides the following definitions:

• The Base Score reflects "the intrinsic and fundamental characteristics of a vulnerability that are constant over time and user environments."


• The Temporal Score reflects "the characteristics of a vulnerability that change over time but not among user environments."


• The Environmental Score reflects "the characteristics of a vulnerability that are relevant and unique to a particular user's environment."

The CVSS Scores provided by Oracle in the Critical Patch Update and Security Alert Advisories are CVSS Base Scores.

Oracle does not provide Temporal Score or Environmental Score for the vulnerabilities fixed in the Critical Patch Updates or Security Alerts. This is mostly because the computation of the Temporal Score by Oracle would have limited value to customers because two of the three factors affecting the Temporal Score would never change (The Remediation Level would always be "Official Fix", and the Report Confidence would always be "Confirmed"). In addition, Oracle cannot compute the Environmental Score because this score is specific to the customers' environment (about which Oracle has no or very little insight).

The Base Scores reported by Oracle in its risk matrices are computed from six criteria, known collectively as the "Base Metrics". These Base Metrics represent "the most fundamental, immutable qualities of a vulnerability". The CVSS documentation states:

"The base metric group captures the characteristics of a vulnerability that are constant with time and across user environments. The Access Vector, Access Complexity, and Authentication metrics capture how the vulnerability is accessed and whether or not extra conditions are required to exploit it. The three impact metrics measure how a vulnerability, if exploited, will directly affect an IT asset, where the impacts are independently defined as the degree of loss of confidentiality, integrity, and availability. For example, a vulnerability could cause a partial loss of integrity and availability, but no loss of confidentiality."

Let's now have a more in-depth look at the 6 Base Metrics.

The first three metrics ("Access Vector", "Access Complexity", and "Authentication") describe where an attack can be launched (Access Vector); related issues such as requirements for social engineering, critical timing or need for high privileges (Access Complexity); and authentication levels required for successful attacks (Authentication). These criteria are designed to provide a good indication of the difficulty of launching a successful attack by people who already have a working exploit.

More specifically:

1. The Access Vector metrics measures how the vulnerability is exploited, and specifically how remote an attacker can be to successfully exploit the vulnerability. The possible Access Vector values are "Local", "Adjacent Network", and "Network". The more remote to the targeted host the attacker can be, the higher the score. For example, the "Network" value is used to describe the most severe vulnerabilities, often referred as "Remotely Exploitable" vulnerabilities.


2. The Access Complexity metrics measures "the complexity of the attack required to exploit the vulnerability once an attacker has gained access to the target system". The possible Access Complexity values are "High", "Medium", and "Low." Obviously, the lower the Access Complexity, the higher the vulnerability score.


3. The Authentication metrics reflects "the number of times an attacker must authenticate to a target in order to exploit a vulnerability." However, "This metric does not gauge the strength or complexity of the authentication process, only that an attacker is required to provide credentials before an exploit may occur." The possible values are "Multiple", "Single", and "None." Obviously, the lower the number of times an attacker has to authenticate, the greater the score of the vulnerability. The most severe vulnerabilities require no authentication (the reported Base Metrics is "None").

In my experience, The Access Complexity metrics is commonly misunderstood. Access complexity does not mean "the degree of difficulty in constructing an exploit". Rather, it means "the degree of difficulty in launching a known exploit". The best way to understand it is through an example. Let's look at 3 hypothetical vulnerabilities:

• The first vulnerability is a RPC (Remote Procedure Call) buffer overflow in a web (Internet) server. Anyone over the Internet can exploit such a vulnerability without requiring any additional steps. As stated in the CVSS standard, there are "no specialized access conditions or extenuating circumstances." The Access Complexity metrics in this example is "Low."


• The second hypothetical vulnerability is a phishing attack, where the victim's web browser is tricked into showing a false link. In such an example, "a small amount of social engineering that might occasionally fool cautious users" exists. The user has to be tricked into clicking the malicious link. The Access Complexity metrics in this example is "Medium."


• The third hypothetical vulnerability is a DNS Hijacking. In such an example, very specific conditions exist to leverage the vulnerability: "the attacking party must already have elevated privileges, or spoof additional systems in addition to the attacking systems." The Access Complexity metrics in this example is "High."

The last 3 Metrics ("Confidentiality Impact", "Integrity Impact", and "Availability Impact") define the possible unauthorized impact of the vulnerability. They are used to assess the confidentiality, integrity, and availability impacts against the targeted system of the successfully exploited vulnerability. The possible values for the three Impact Metrics are the same: they are "None", "Partial", and "Complete."
In my experience, while the scope of the confidentiality, integrity, and availability (CIA) impacts are mostly well understood, the determination of their respective score is perhaps the least understood aspect of the CVSS Base Score. There seems to be some confusion about the use of "Partial" vs. "Complete." The following information is directly extracted from the CVSS Guide:

1. Confidentiality Impact Scoring Evaluation:

• None (N) - There is no impact to the confidentiality of the system.
• Partial (P) - There is considerable informational disclosure. Access to some system files is possible, but the attacker does not have control over what is obtained, or the scope of the loss is constrained.
• Complete (C) - There is total information disclosure, resulting in all system files being revealed. The attacker is able to read all of the system's data (memory, files, etc.)

2. Integrity Impact Scoring Evaluation:

• None (N) - There is no impact to the integrity of the system.
• Partial (P) - Modification of some system files or information is possible, but the attacker does not have control over what can be modified, or the scope of what the attacker can affect is limited.
• Complete (C) - There is a total compromise of system integrity. There is a complete loss of system protection, resulting in the entire system being compromised. The attacker is able to modify any files on the target system.

3. Availability Impact Scoring Evaluation:

• None (N) - There is no impact to the availability of the system.
• Partial (P) - There is reduced performance or interruptions in resource availability.
• Complete (C) - There is a total shutdown of the affected resource. The attacker can render the resource completely unavailable.

The above definitions imply that when a system's compromise is limited to the software layer in which the vulnerability resides (e.g. a database), the reported value must be "Partial." However, when the successful exploit of the vulnerability results in a full compromise down to the Operating Systems level, the reported value must be "Complete."

Oracle always tries to follow the standard in the application of these scores, and where it is ambiguous, Oracle tries to follow the common usage in the industry. The standard and the industry treat these values as "No Impact" for "none", "Partial Impact" for "Partial" and "Complete compromise of the Operating System where the code is executing" for "Complete". This means that, for example, a complete compromise limited to the Oracle Database Server , but not resulting in completely compromising the Operating System where the Database executes, is considered "Partial".

However, Oracle determined that many customers consider a complete compromise of the Database or other components, just as important as a complete compromise of the Operating System where the Database executes. Consequently, in order to convey the information that the impact is a complete compromise of the affected component, Oracle created the "Partial+" custom score. Oracle uses the Partial numeric value assigned by CVSS for both Partial and Partial+, so that Oracle does not deviate from a strict application of the standard. However, Oracle recognizes that some organizations may choose to deviate from the CVSS standard and discretely inflate the Base Score when a value of Partial + is reported by Oracle in the Critical Patch Update and Security Alert risk matrices. This approach was chosen after Oracle considered using a "Complete minus" score, which would score like an OS complete compromise, but we rejected this approach as it would clearly violate the CVSS standard.

A basic understanding of the CVSS Base Score can bring organizations a long way in understanding the severity of the vulnerabilities fixed in a given CPU or Security Alert. The following rules of thumb can be used to keep CVSS Base Score in proper perspective:

• A CVSS Base Score greater than 7.5 indicates a compromise down to the Operating System of the targeted system where the product executes.


• A value of 10.0 indicates an easy, over the network, unauthenticated, and full takeover down to the Operating System where the product executes.


• A value of 9.0 typically indicates a relatively easy, over the network, and full takeover of the system down to the Operating System, where the product executes, but a low privilege authentication is required.


• A value of 7.5 with no "Complete" value reported in the impact columns of the risk matrix indicates an easy, over the network unauthenticated takeover of the product. (A value of 6.5 would be reported if all impacts were reported as "Partial+" and if authentication was required.)

In January 2011 (with the release of the January 2011 Critical Patch Update), Oracle enhanced the Critical Patch Update documentation by starting to publish a plain English version of the risk matrices contained in the Critical Patch Update advisory. This text summary of the risk matrices will include the same information as the standard risk matrices, and is designed for individuals who are not yet very familiar with the application of the CVSS standard and its interpretation. The link for the plain English version of the risk matrices is provided in each Critical Patch Update advisory (for example, the Advisory for the January 2011 CPU is located here, and the plain English version of the risk matrices is located here). I highly recommend that administrators, who need to consult the CPU advisories, take advantage of the plain English version of the risk matrices to become familiar with the CVSS Standard and its application by Oracle.

For More Information:

• The white paper "Recommendations for leveraging the Critical Patch Update & maintaining a proper security posture" is located at http://www.oracle.com/us/support/assurance/leveraging-cpu-wp-164638.pdf. This white paper has an extensive section on how to properly interpret Oracle's risk matrices.


• Support Note 394487.1 (subscription to My Oracle Support required) explains Oracle's implementation of the CVSS standard.

Hi, this is Eric Maurice again!

A few years ago, I posted a blog entry, which discussed the psychology of patching. The point of this blog entry was that a natural tendency existed for systems and database administrators to be reluctant to apply patches, even security patches, because of the fear of "breaking" the system. Unfortunately, this belief in the principle "if it ain't broke, don't fix it!" creates significant risks for organizations. Running systems without applying the proper security patches can greatly compromise the security posture of the organization because the security controls available in the affected system may be compromised as a result of the existence of the unfixed vulnerabilities. As a result, Oracle continues to strongly recommend that customers apply all security fixes as soon as possible.

Most recently, I have had a number of conversations with customers who questioned the need to upgrade their highly stable but otherwise unsupported Oracle systems. These customers wanted to know more about the kind of security risks they were exposed to, by running obsolete versions of Oracle software.

As per Oracle Support Policies, Critical Patch Updates are produced for currently supported products. In other words, Critical Patch Updates are not created by Oracle for product versions that are no longer covered under the Premier Support or Extended Support phases of the Lifetime Support Policy.

One statement used in each Critical Patch Update Advisory is particularly important:

"We recommend that customers upgrade to a supported version of Oracle products in order to obtain patches. Unsupported products, releases and versions are not tested for the presence of vulnerabilities addressed by this Critical Patch Update. However, it is likely that earlier versions of affected releases are also affected by these vulnerabilities."

The purpose of this warning is to inform Oracle customers that a number of the vulnerabilities fixed in each Critical Patch Update may affect older versions of a specific product line. In other words, each Critical Patch Update provides a number of fixes for currently supported versions of a given product line (this information is listed for each bug in the Risk Matrices of the Critical Patch Update Advisory), but the unsupported versions in the same product line, while they may be affected by the vulnerabilities, will not receive the fixes, and are therefore vulnerable to attacks.

The risk assumed by organizations wishing to remain on unsupported versions is amplified by the behavior of malicious hackers, who typically will attempt to, and sometimes succeed in, reverse-engineering the content of vendors' security fixes. As a result, it is not uncommon for exploits to be published soon after Oracle discloses vulnerabilities with the release of a Critical Patch Update or Security Alert.

Let's consider now the nature of the vulnerabilities that may exist in obsolete versions of Oracle software.

A number of severe vulnerabilities have been fixed by Oracle over the years. While Oracle does not test unsupported products, releases and versions for the presence of vulnerabilities addressed by each Critical Patch Update, it should be assumed that a number of the vulnerabilities fixed with the Critical Patch Update program do exist in unsupported versions (regardless of the product considered). The most severe vulnerabilities fixed in past Critical Patch Updates may result in full compromise of the targeted systems, down to the OS level, by remote and unauthenticated users (these vulnerabilities receive a CVSS Base Score of 10.0) or almost as critically, may result in the compromise of the affected systems (without compromising the underlying OS) by a remote and unauthenticated users (these vulnerabilities receive a CVSS Base Score of 7.5). Such vulnerabilities may result in complete takeover of the targeted machine (for the CVSS 10.0), or may result in allowing the attacker the ability to create a denial of service against the affected system or even hijacking or stealing all the data hosted by the compromised system (for the CVSS 7.5). The bottom line is that organizations should assume the worst case: that the most critical vulnerabilities are present in their unsupported version; therefore, it is Oracle's recommendation that all organizations move to supported systems and apply security patches in a timely fashion.

Organizations that currently run supported versions but may be late in their security patch release level can quickly catch up because most Critical Patch Updates are cumulative. With a few exceptions noted in Oracle's Critical Patch Update Advisory, the application of the most recent Critical Patch Update will bring these products to current security patch level and provide the organization with the best possible security posture for their patch level.

Furthermore, organizations are encouraged to upgrade to most recent versions as this will greatly improve their security posture. At Oracle, our security fixing policies state that security fixes are produced for the main code line first, and as a result, our products benefit from the mistakes made in previous version(s). Our ongoing assurance effort ensures that we work diligently to fix the vulnerabilities we find, and aim at constantly improving the security posture our products provide by default. Patch sets include numerous in-depth fixes in addition to those delivered through the Critical Patch Update and, in certain instances, important security fixes require major architectural changes that can only be included in new product releases (and cannot be backported through the Critical Patch Update program).

For More Information:

• Mary Ann Davidson is giving a webcast interview on Oracle Software Security Assurance on February 24th. The registration link for attending this webcast is located at http://event.on24.com/r.htm?e=280304&s=1&k=6A7152F62313CA09F77EBCEEA9B6294F&partnerref=EricMblog

• A blog entry discussing Oracle's practices for ensuring the quality of Critical patch Updates can be found at http://blogs.oracle.com/security/2009/07/ensuring_critical_patch_update_quality.html

• The blog entry "To patch or not to patch" is located at http://blogs.oracle.com/security/2008/01/to_patch_or_not_to_patch.html

• Oracle's Support Policies are located at http://www.oracle.com/us/support/policies/index.html

• The Critical Patch Update & Security Alert page is located at http://www.oracle.com/technetwork/topics/security/alerts-086861.html

Hello, this is Eric Maurice again.

Oracle released the February 2011 Critical Patch Update for Java SE and Java for Business today. As discussed in a previous blog entry, Oracle currently maintains a separate Critical Patch Update schedule for Java SE and Java for Business because of commitments made prior to the Oracle acquisition in regards to the timing for the publication of Java fixes.

Today's Java Critical Patch Update includes fixes for 21 vulnerabilities. The most severe CVSS Base Score for vulnerabilities fixed in this CPU is 10.0, and this Base Score affects 8 vulnerabilities.

Out of these 21 vulnerabilities, 13 affect Java client deployments. 12 of these 13 vulnerabilities can be exploited through Untrusted Java Web Start applications and Untrusted Java Applets, which run in the Java sandbox with limited privileges. One of these 13 vulnerabilities can be exploited by running a standalone application.

In addition, one of the client vulnerability affects Java Update, a Windows-specific component.

3 of the 21 vulnerabilities affect client and server deployments. These vulnerabilities can be exploited through Untrusted Java Web Start applications and Untrusted Java Applets, as well as be exploited by supplying malicious data to APIs in the specified components, such as, for example, through a web service.

3 vulnerabilities affect Java server deployments only. These vulnerabilities can be exploited by supplying malicious data to APIs in the specified Java components. Note that one of these vulnerabilities (CVE-2010-4476) was the subject of a Security Alert released on February 8th.

Finally, one of these vulnerabilities is specific to Java DB, a component in the Java JDK, but not included in the Java Runtime Environment (JRE).

As usual, because of the severity of the vulnerabilities fixed in this Critical Patch Update, Oracle recommends that Java customers apply it as soon as possible. The Critical Patch Advisory provides more details about the vulnerabilities addressed in the Critical Patch Update as well as instructions on how to install the fixes and where to get them. Home users should use the Java auto-update mechanism to install the latest version of the Java Runtime Environment 6 update 24 or higher (JRE), which includes the fix for this vulnerability.

For More Information:

The Critical Patch Updates and Security Alerts page is located at http://www.oracle.com/technetwork/topics/security/alerts-086861.html

More information on Oracle Software Security Assurance is located at http://www.oracle.com/us/support/assurance/index.html

Consumers can go to http://www.java.com/en/download/installed.jsp to ensure that they have the latest version of Java running on their desktops. More information on Java Update is available at http://www.java.com/en/download/help/java_update.xml

Hello, this is Eric Maurice again.

Oracle just released a Security Alert with a fix for the vulnerability CVE-2010-4476, which affects Oracle Java SE and Oracle Java For Business. This vulnerability is present in Java running on servers as well as standalone Java desktop applications. Its successful exploitation by a malicious attacker can result in a complete denial of service for the affected servers.

While only recently publicly disclosed, a number of Internet sites have since then reproduced details about this vulnerability, including exploit codes, which may result in allowing a malicious attacker to create a denial of service condition against the targeted system. Oracle therefore strongly recommends that affected organizations apply this fix as soon as possible. The Security Alert Advisory provides information on how to apply this fix and where to download it. In addition, note that the fix for this vulnerability will also be included in the upcoming Java Critical Patch Update (Java SE and Java for Business Critical Patch Update - February 2011), which will be released on February 15th 2011.

Note that the impact of this vulnerability on desktops is minimal: the affected applications or applets running in Internet browsers for example, might stop responding and may need to be restarted; however the desktop itself will not be compromised (i.e. no compromise at the desktop OS level). Oracle therefore recommends that consumers use the Java auto-update mechanism to get this fix. This will prompt them to install the latest version of the Java Runtime Environment 6 update 24 or higher (JRE), which includes the fix for this vulnerability. JRE 6 update 24 will also be distributed with the Java SE and Java for Business Critical Patch Update - February 2011.

For More Information:

The Critical Patch Updates and Security Alerts page is located at http://www.oracle.com/technetwork/topics/security/alerts-086861.html

The Advisory for Security Alert CVE-2010-4476 is located at http://www.oracle.com/technetwork/topics/security/alert-cve-2010-4476-305811.html

More information on Oracle Software Security Assurance is located at http://www.oracle.com/us/support/assurance/index.html

Consumers can go to http://www.java.com/en/download/installed.jsp to ensure that they have the latest version of Java running on their desktops. More information on Java Update is available at http://www.java.com/en/download/help/java_update.xml

Hi, this is Eric Maurice again.

Oracle released the January 2011 Critical Patch Update (CPUJan2011) today. With this Critical Patch Update (CPU), Oracle's primary security vulnerability remediation program enters its seventh year (the first Critical Patch Update was released in January 2005). The program continues to provide customers with a consistent mechanism for the distribution of security fixes across all Oracle products. CPUs are issued on a predictable schedule published a year in advance. The CPU documentation, and more specifically, the risk matrices used to provide information about the nature and criticality of the vulnerabilities fixed in each CPU are consistent across all product lines and leverage industry standards such as CVSS (to provide an indication of the criticality of each vulnerability) and CVE (to provide a unique identifier for each vulnerability). Very importantly as well, Oracle's fixing and disclosure policies are transparent and are designed to provide equal protection to all Oracle customers.

Today's Critical Patch Update (CPUJan2011) provides fixes for 66 security vulnerabilities across a wide range of products including: Oracle Database Server, Oracle Secure Backup, Oracle Audit Vault, Oracle Database Vault, Oracle Fusion Middleware, Oracle Enterprise Manager Grid Control, Oracle Applications, Oracle Industry Applications, Oracle PeopleSoft Enterprise, Oracle Solaris, and Oracle Open Office.

6 of the 66 security vulnerabilities affect Oracle Database Server including Oracle Database Vault. The most severe of these 6 vulnerabilities affects Oracle Enterprise Manager Grid Control, and received a CVSS Base Score of 7.5. In addition, a fix for an Oracle Audit Vault vulnerability which has received a CVSS Base Score of 10.0 is also provided in today's CPU. As usual, Oracle recommends that customers apply this Critical Patch Update as soon as possible so that they can maintain their security in-depth posture regardless of the existence of external mitigation factors that may prevent the exploitation of these vulnerabilities (e.g. network access controls, etc.)

16 fixes were released for Oracle Fusion Middleware. The maximum CVSS score for Oracle Fusion Middleware is 10.0 for 2 separate vulnerabilities. The first, for JRockit, refers to a set of Java Runtime Environment security fixes that were previously released by Oracle. The second one affects the Node Manager component of Oracle WebLogic Server.

11 fixes were released for Oracle PeopleSoft Enterprise. The maximum CVSS Base Score for these vulnerabilities is 7.5. It is for a single vulnerability affecting PeopleSoft 8.50 and 8.51. This vulnerability was publicly disclosed accidentally earlier this month. Oracle highly recommends that PeopleSoft customers apply this Critical Patch Update as soon as possible as a result of this accidental disclosure.

This Critical Patch Update also includes fixes for 21 new vulnerabilities affecting the Oracle Sun product family and 2 new vulnerabilities affecting Oracle Open Office. The most severe vulnerability affecting the Sun Product family affects Oracle Solaris with a CVSS Base Score of 10.0.

The 2 vulnerabilities affecting Oracle Open Office received a CVSS Base Score of 9.3 and are related to exploit conditions that exist when malicious attachments are opened by unsuspecting users. Oracle reported a 9.3 CVSS Base Score for these Open Office vulnerabilities because many users, particularly Windows XP users, run with administrative privileges. However, the CVSS Base Score for these vulnerabilities falls to 6.8 when these malicious attachments are opened by users with limited privileges.

Sun customers, who wish to consult the Security Sun Alert notifications published before April 2010 can do so by visiting the "Sun Alert Archive and Mappings for Legacy SunSolve Document ID Numbers" page located at http://www.oracle.com/technetwork/topics/security/sunalertslisting-197036.html

With today's Critical Patch Update, Oracle introduces an enhancement to the Critical Patch Update documentation. As a result of customer feedback, Oracle will now publish a plain English version of the risk matrices. This document can be found at http://www.oracle.com/technetwork/topics/security/cpujan2011verbose-194110.html. This text summary of the risk matrices will always include the same information as the standard risk matrices, and is designed for individuals who may not be very familiar with the application of the CVSS standard and its interpretation.

Finally, Oracle recently published a technical white paper titled "Recommendations for Leveraging the Critical Patch Update and Maintaining a Proper Security Posture" in an attempt to document the practices of a number of organizations, which had adopted repeatable processes to deal with the Critical Patch Updates. This white paper is located at http://www.oracle.com/us/support/assurance/leveraging-cpu-wp-164638.pdf, and is a good starting point for administrators who may be new to the Critical Patch Update or feel overwhelmed with the prospect of patching their systems.

For More Information:
"Inclusion Of Security Fixes For Externally Reported Security Bugs In The Critical Patch Updates", a blog entry by Clement Chen, can be found at http://blogs.oracle.com/security/2010/11/inclusion_of_security_fixes_fo.html

The Critical Patch Updates and Security Alerts page is located at : http://www.oracle.com/technetwork/topics/security/alerts-086861.html

More information about Oracle Software Security Assurance, including Oracle security fixing policies, is available on: http://www.oracle.com/us/support/assurance/index.html

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

Security Sun Alert notifications prior to April 2010 for Sun products are located at http://www.oracle.com/technetwork/topics/security/sunalertslisting-197036.html

Hi, this is Shaomin Wang. I am a security analyst in Oracle's Security Alerts Group. My primary responsibility is to evaluate the security vulnerabilities reported externally by security researchers on Oracle Fusion Middleware and to ensure timely resolution through the Critical Patch Update. Today, I am going to talk about a serious type of attack: Connection String Parameter Pollution (CSPP).

Earlier this year, at the Black Hat DC 2010 Conference, two Spanish security researchers, Jose Palazon and Chema Alonso, unveiled a new class of security vulnerabilities, which target insecure dynamic connections between web applications and databases. The attack called Connection String Parameter Pollution (CSPP) exploits specifically the semicolon delimited database connection strings that are constructed dynamically based on the user inputs from web applications.

CSPP, if carried out successfully, can be used to steal user identities and hijack web credentials. CSPP is a high risk attack because of the relative ease with which it can be carried out (low access complexity) and the potential results it can have (high impact).

In today's blog, we are going to first look at what connection strings are and then review the different ways connection string injections can be leveraged by malicious hackers. We will then discuss how CSPP differs from traditional connection string injection, and the measures organizations can take to prevent this kind of attacks.

In web applications, a connection string is a set of values that specifies information to connect to backend data repositories, in most cases, databases. The connection string is passed to a provider or driver to initiate a connection. Vendors or manufacturers write their own providers for different databases. Since there are many different providers and each provider has multiple ways to make a connection, there are many different ways to write a connection string. Here are some examples of connection strings from Oracle Data Provider for .Net/ODP.Net:

Oracle Data Provider for .Net / ODP.Net; Manufacturer: Oracle; Type: .NET Framework Class Library:
- Using TNS
Data Source = orcl; User ID = myUsername; Password = myPassword;
- Using integrated security
Data Source = orcl; Integrated Security = SSPI;
- Using the Easy Connect Naming Method
Data Source = username/password@//myserver:1521/my.server.com
- Specifying Pooling parameters
Data Source=myOracleDB; User Id=myUsername; Password=myPassword; Min Pool Size=10; Connection Lifetime=120; Connection Timeout=60; Incr Pool Size=5; Decr Pool Size=2;

There are many variations of the connection strings, but the majority of connection strings are key value pairs delimited by semicolons.

Attacks on connection strings are not new (see for example, this SANS White Paper on Securing SQL Connection String). Connection strings are vulnerable to injection attacks when dynamic string concatenation is used to build connection strings based on user input. When the user input is not validated or filtered, and malicious text or characters are not properly escaped, an attacker can potentially access sensitive data or resources.

For a number of years now, vendors, including Oracle, have created connection string builder class tools to help developers generate valid connection strings and potentially prevent this kind of vulnerability. Unfortunately, not all application developers use these utilities because they are not aware of the danger posed by this kind of attacks.

So how are Connection String parameter Pollution (CSPP) attacks different from traditional Connection String Injection attacks?

First, let's look at what parameter pollution attacks are. Parameter pollution is a technique, which typically involves appending repeating parameters to the request strings to attack the receiving end. Much of the public attention around parameter pollution was initiated as a result of a presentation on HTTP Parameter Pollution attacks by Stefano Di Paola and Luca Carettoni delivered at the 2009 Appsec OWASP Conference in Poland.

In HTTP Parameter Pollution attacks, an attacker submits additional parameters in HTTP GET/POST to a web application, and if these parameters have the same name as an existing parameter, the web application may react in different ways depends on how the web application and web server deal with multiple parameters with the same name.

When applied to connections strings, the rule for the majority of database providers is the "last one wins" algorithm. If a KEYWORD=VALUE pair occurs more than once in the connection string, the value associated with the LAST occurrence is used. This opens the door to some serious attacks.

By way of example, in a web application, a user enters username and password; a subsequent connection string is generated to connect to the back end database.

Data Source = myDataSource; Initial Catalog = db; Integrated Security = no; User ID = myUsername; Password = XXX;

In the password field, if the attacker enters "xxx; Integrated Security = true", the connection string becomes,

Data Source = myDataSource; Initial Catalog = db; Integrated Security = no; User ID = myUsername; Password = XXX; Intergrated Security = true;

Under the "last one wins" principle, the web application will then try to connect to the database using the operating system account under which the application is running to bypass normal authentication.

CSPP poses serious risks for unprepared organizations. It can be particularly dangerous if an Enterprise Systems Management web front-end is compromised, because attackers can then gain access to control panels to configure databases, systems accounts, etc. Fortunately, organizations can take steps to prevent this kind of attacks.

CSPP falls into the Injection category of attacks like Cross Site Scripting or SQL Injection, which are made possible when inputs from users are not properly escaped or sanitized. Escaping is a technique used to ensure that characters (mostly from user inputs) are treated as data, not as characters, that is relevant to the interpreter's parser.

Software developers need to become aware of the danger of these attacks and learn about the defenses mechanism they need to introduce in their code. As well, software vendors need to provide templates or classes to facilitate coding and eliminate developers' guesswork for protecting against such vulnerabilities. Oracle has introduced the OracleConnectionStringBuilder class in Oracle Data Provider for .NET. Using this class, developers can employ a configuration file to provide the connection string and/or dynamically set the values through key/value pairs. It makes creating connection strings less error-prone and easier to manager, and ultimately using the OracleConnectionStringBuilder class provides better security against injection into connection strings.

For More Information:
- The OracleConnectionStringBuilder is located at http://download.oracle.com/docs/cd/B28359_01/win.111/b28375/OracleConnectionStringBuilderClass.htm
- Oracle has developed a publicly available course on preventing SQL Injections. The Server Technologies Curriculum course "Defending Against SQL Injection Attacks!" is located at http://st-curriculum.oracle.com/tutorial/SQLInjection/index.htm
- The OWASP web site also provides a number of useful resources. It is located at http://www.owasp.org/index.php/Main_Page

Hello, my name is Clement Chen. I am a principal security analyst in Oracle's Security Alerts Group. My primary responsibility is to triage externally reported security vulnerabilities and to ensure their timely resolution through Oracle's Critical Patch Update program, which is Oracle's primary means of releasing security fixes for all Oracle products.

In today's blog I will answer a question I am often asked. This question is "what are the criteria used by Oracle to decide whether a vulnerability warrants a fix in the CPU?"

The criteria used by Oracle to decide whether a vulnerability warrants a fix in the CPU are simple. All externally reported exploitable security vulnerabilities are considered for inclusion in the Critical Patch Update.

Obviously, to understand this policy, one must first understand what we consider to be an "exploitable vulnerability". In my group, we define a software flaw as an "exploitable" security vulnerability if it passes the following two tests:
(1) There is at least one attack surface through which the flaw can be exploited.
(2) If exploited, the software flaw has a non zero CVSS impact which allows attacker to:
- see or acquire data he/she should not have access to (confidentiality); and/or
- modify data he/she should not have access to (integrity); and/or
- prevent other users to access shared data or system resources, when he/she should not be able to (availability).

The first test looks at the existence of an attack surface for the vulnerability. In practice, it is not always straightforward to find attack surfaces where a software flaw can be exploited. In some cases, an attack surface only exists in a small time window; in other cases, an attack surface is only present when software is under some specific configurations. Thus, we always spend a significant amount of time trying to get a full and accurate understanding of the reported issue and its implication. We consider the first test failed only in cases where we are sure that no attack surface exists for a software flaw. In certain instances, the flaw is not directly exploitable by itself but can only be exploited when combined with other vulnerabilities. In this case (blended threat), we generally do not consider it as "exploitable". In the rare cases where we cannot decide, we tend to err on the side of being cautious, and will deem the flaw as "exploitable".

The second test looks at the security impact caused by the software flaw if it is successfully exploited. The impact is usually measured using the confidentiality, integrity, and availability metrics. The scope of the impact will also be considered: that is, whether the impact is limited to the realm of the affected software, or whether it can be extended to the whole operating system (as in a full system compromise).

In the context of this second test, Oracle uses the Common Vulnerability Scoring System (CVSS) definitions of "impact". Since Eric Maurice, in an earlier blog entry, discussed CVSS, I will not discuss again the standards in detail, except to state that, while the CVSS Base Score cannot capture all the subtleties of security flaws, it makes it simple, understandable, and easy to compare security vulnerabilities. A CVSS Base Score ranges from 0 to 10.0. Simply put, a CVSS score above zero means that a software flaw will have some security impact if exploited. A CVSS score of zero means that the software flaw has no security impact. Thus, Oracle considers all externally reported vulnerabilities that have a non-zero CVSS base score as candidates for inclusion in a Critical Patch Update.

It has been my experience that the application of these two tests tends to result in classifying many software flaws as "exploitable" security vulnerabilities. In fact, most of the vulnerability reports my group has received are exploitable security vulnerabilities. It is much more difficult to come with examples of security flaws that would be classified as not exploitable security vulnerabilities under these two tests. The following three examples will help you understand what we think is NOT an exploitable security vulnerability:
• Example 1: A SQL injection issue in a private PL/SQL routine is not an exploitable security vulnerability as long as there is no known path to it from public routines. This is because there is no publicly available attack surface (the first criteria).
• Example 2: A SQL injection issue in a PL/SQL routine that is to be run as invoker's right is not an exploitable security vulnerability as long as there is no known path to the invoker's rights routine from a definer's rights routine. This is because invoker's rights means that the PL/SQL routine runs with the privilege of the caller so no privilege escalation is possible. However, if the routine is a definer's rights routine and it could have higher privileges than an attacker, then privilege escalation is possible and CVSS base score will be greater than zero.
• Example 3: A buffer overflow issue that can ONLY cause a crash of the current user session is NOT an exploitable security vulnerability. Here, "only" means that the crash would not put the database in an unstable state and the crash does not produce a huge trace file on the system to fill up the disk space. In this case, while there is an attack surface, there is no real security impact - one can simply type "quit" to have the same impact.

I'd like to point out that, while non-exploitable security flaws do not necessarily warrant a fix in a CPU; it does not mean that we won't take any action! For example, the SQL injection issues I mentioned above will still be fixed because we understand that, as a good security practice, all inputs needs to be sanitized before their use. We will however deliver the appropriate fix as part of a patch set or in a future release of the product, rather than through the CPU program.

Oracle has also put in place a means to recognize those external researchers who discover issues that may not always be classified as exploitable vulnerabilities. Starting with the July 2008 CPU, Oracle has instituted a Security-In-Depth recognition program to provide credit to people who provide information, observations or suggestions to Oracle pertaining to security issues that result in significant modifications of Oracle code or documentation in future releases, but are not of such a critical nature that they are distributed in Critical Patch Updates.

For More Information:

The Critical Patch Updates and Security Alerts page is located at http://www.oracle.com/technetwork/topics/security/alerts-086861.html

Oracle Software Security Assurance web site is located at http://www.oracle.com/us/support/assurance/index.html

Hello, this is Denis Pilipchuk again.

In a previous blog entry, we discussed how blackbox fuzz testing of Web Applications is a popular method for product security testing. Though this kind of tool is commonly used, the process for selecting one is not as straightforward as one would imagine.

Arguably, the greatest challenge with selecting the proper tool results from the continual race between blackbox fuzzing tools and Web technologies. For example, the transition of web applications from Web 1.0 to Web 2.0 has caused great difficulties to all of the blackbox fuzzing tools vendors because of the rich user interactive content and dynamically generated links typically introduced by Web 2.0 applications. This race, along with the facts that the standards in this area are very loose, and that each implementation of web 2.0 standard is slightly (or not so slightly) different, prevent even the most advanced tools from being able to successfully navigate and test websites based on newer technology.

Some of the tools currently on the market do not even currently have the capability to deal with Web 2.0 applications. Others, which claim that they are "Web 2.0 compliant", turn out to be compatible only with certain implementations. In pretty much all instances I have seen while dealing with blackbox Web application scanners, even automated navigation of such applications (discovery) presents huge problems and requires manual intervention from the tester.

One of the logical impacts of this permanent technology race is that it often turns yesterday's leaders into tomorrow's outsiders. More importantly, this constant state of catch up between testing tools and Web technology greatly challenges potential customers when conducting tools evaluations in the absence of any standards or even mutually agreed practices in the industry. If one wants to compare several blackbox fuzzing tools, where does one start?

The National Institute of Standards and Technology (NIST) is trying to answer this question for static analysis tools with the SATE project, which aims at evaluating the effectiveness of these tools. But to date, nothing comparable has been done in the area of dynamic analysis tools. The closest I can think of in terms of comparison was Larry Suto's analysis of several blackbox fuzzing tools and services, which was published in February 2010. This analysis was definitely an admirable effort and an eye-opener for many people, but to be truly useful, it would need to become a more formal exercise, published on a regular schedule.

At the beginning of the evaluation of a fuzzing tool, testers must ask themselves: "what is the desired configuration - Point-and-Shoot (PaS) or trained?" Point-and-Shoot (PaS) mode implies that the tool is just aimed at the root URL of a Web application and is capable of discovering and testing the links itself (with the exception of login configuration), whereas "Trained" mode, requires varying degree of involvement on the part of the tester, ranging from creating specialized login macros to manually following links to be tested and specifying the fields and parameters for fuzzing.

Many vendors claim that the PaS mode is not fair and should not be used in practice, but this is exactly how many IT security people deploy these tools because they simply do not have time to train themselves to deal with each of the specific applications they need to test. IT security folks will generally rely on the default tool configuration instead.

So, what makes comparing these tools so difficult? There are no standard benchmarks to evaluate against, no commonly used metrics to measure up to, and no compatible reporting. Many tool vendors maintain test sites to showcase their respective technologies (see for example http://securitythoughts.wordpress.com/2010/03/22/vulnerable-web-applications-for-learning/), but those sites are naturally biased toward an individual vendor's own product and can be updated at any given time, which makes them unsuitable as a reliable benchmark.

All tools report their findings in different formats, often categorizing same issues differently and assigning them different priorities. It takes a great deal of effort to go through assessment reports from two different vendors and compare their findings. On top of that, tools often detect the same vulnerability through multiple attack vectors and report it multiple times in different sections of the report, further complicating the comparison. Additional effort is also required to identify false positives and false negatives in these reports, as careful analysis of all reports against the site in question is necessary.

The lack of metrics presents another problem for these comparisons. The only significant effort in this area, WASSEC (Web Application Security Scanner Evaluation Criteria) concentrates on defining tools comparison metrics and provides a pretty comprehensive and useful analysis framework, but it has not been yet widely adopted in the industry.

Further refinement of the WASSEC metrics, and the incorporation of this methodology into a regularly published report along the lines of Larry Suto's report, would be a huge step toward achieving consistency of analysis across blackbox fuzzing tools. Conceivably, this could be an ongoing project, supported by the most prominent industry players and maintained by an independent organization like NIST or an academic institution.

Hello, this is Eric Maurice.

Oracle today released the October 2010 Critical Patch Update (CPUOct2010), the third Critical Patch Update to include fixes for the Sun product line, and a Critical Patch Update for Java.

Security fixes for Java SE and Java for Business are included in a separate Critical Patch Update because the publication schedule of the Java fixes is not the same as the publication schedule of the Critical Patch Update for other Oracle products. These different schedules are due to commitments made to Java customers prior to the Sun acquisition. In 2011, 3 separate Critical Patch Updates for Java will be issued. Only one of these Java Critical Patch Updates should be released on the same day as the normal Critical Patch Update (on October 18, 2011).

Today's Critical patch Update for Java includes fixes for 29 new security vulnerabilities. 15 of these 29 vulnerabilities yield a CVSS Base Score of 10.0 affecting multiple components of Java. Oracle therefore recommends that Java customers apply this Critical Patch Update as soon as possible.

The October 2010 CPU (CPUOct2010) provides 85 new security fixes, 31 of which are for Oracle Sun products (i.e., former Sun product lines). The following product families are affected: Oracle Database Server, Oracle Fusion Middleware, Oracle Enterprise Manager, Oracle E-Business Suite and Supply Chain Products Suite, Oracle PeopleSoft Enterprise, Oracle Siebel CRM, Oracle Primavera, Oracle VM, and as previously discussed, the Oracle Sun product line (including OpenOffice).

7 of the new vulnerabilities fixed in the October 2010 CPU are for Oracle Database Server, and only one of these vulnerabilities is remotely exploitable without authentication. The maximum CVSS score for these vulnerabilities is 6.5. Oracle continues to recommend that Database customers apply this Critical Patch Update as soon as possible in order to maintain their defense in depth posture. Database customers should also familiarize themselves with the patching options provided to them, and consider the use of Patch Set Update patches as opposed to traditional CPU patches (when applicable). See the following blog entry to learn more about the benefits of the Patch Set Update format of patches.

Note that the Oracle Enterprise Manager Grid Control vulnerability only affects Application Server and Database Server Control deployments. The exposure to these products depends on the version that has been deployed. Oracle therefore recommends that customers apply this patch and refer to My Oracle Support Note 1159443.1 for more information.

A significant portion of the newly fixed vulnerabilities in this Critical Patch Update affect Oracle Sun products. While the continuous inclusion of new product lines in the Critical Patch Update program affects the identification of any kind of meaningful trends in overall CPU size, it demonstrates the flexibility of the program. It also demonstrates a conscious desire to simplify as much as possible the security patch management tasks for its customers. From a customer perspective, there are strong advantages in getting all security patches for related products across all supported platforms and versions combinations on a single day, whose date is announced with a year notice.

The Oracle Sun products affected by the 31 new vulnerabilities fixed in this CPU include Oracle Solaris and OpenSolaris, Oracle OpenOffice, Sun Convergence, and Oracle Sun Directory Server Enterprise Edition. With a CVSS Base Score of 10.0. and 9.0, the two most critical vulnerabilities for products other than OpenOffice affect Solaris and OpenSolaris respectively.

This CPU includes 5 new fixes for OpenOffice, to address vulnerabilities that have all received a CVSS Base Score of 9.3 to reflect deployment scenarios when OpenOffice is used by a user with root or administrator privileges. When OpenOffice is used by a user with limited OS privileges, the CVSS Base Score is 6.8, reflecting the fact that a successful exploitation of one of these vulnerabilities cannot result in a full compromise down to the OS when the application is run with limited (i.e. non root or administrative) privileges. OpenOffice customers can get these security patches now, without waiting for the next automated update, by using the "check for updates" feature in OpenOffice.

For more information:

• The Critical Patch Updates and Security Alerts page is located at : http://www.oracle.com/technetwork/topics/security/alerts-086861.html


• A short document describing the changes in security policies for the Sun product lines is available at : http://www.oracle.com/technetwork/topics/security/changesforsunsecuritypolicies-162219.html


• More information about Oracle Software Security Assurance, including Oracle security fixing policies, is available on: http://www.oracle.com/us/support/assurance/index.html

Hi, this is Eric Maurice.

In a previous blog entry, we invited customers to provide feedback in regards to the content of the Critical Patch Update advisory for Oracle Sun products. Such feedback is very valuable, and continues to drive the definition of Oracle Software Security Assurance policies.

As a result of the feedback received, Oracle has updated its policies to include the mapping of each vulnerability's CVE number to the particular Solaris package patch version (patchid), in all future Solaris CPU Patch Availability Documents. The updated policy will be effective with the October 2010 Critical Patch Update onward.

With the Critical Patch Update, Oracle's objective is to positively influence the security posture of all customers by providing the most effective vulnerability remediation program in the industry. This means not only producing effective, fully tested, security patches on all supported platform and version combinations every quarter, but also providing sufficient information about the newly-fixed vulnerabilities to enable customers to make proper patching decision and effectively manage their security management costs.

For More Information:

• The Critical Patch Updates and Security Alerts page is located at http://www.oracle.com/technology/deploy/security/alerts.htm


• A short document describing the changes in security policies for the Sun product lines is available at http://www.oracle.com/technetwork/topics/security/changesforsunsecuritypolicies-162219.html


• More information about Oracle Software Security Assurance is available on http://www.oracle.com/us/support/assurance/index.html

The Critical Patch Update program (CPU) is Oracle's primary mechanism for the release of security fixes for all Oracle products. Introduced in January 2005, Critical Patch Updates are released on dates announced a year in advance. Critical Patch Update patches correct security vulnerabilities and may, when required, include fixes that are prerequisites for the security fixes.

In July 2009, Oracle introduced a new patch offering specific to Oracle Database Server: the Patch Set Update (PSU). More recently, Patch Set Updates for Oracle Enterprise Manager 10.2.0.5 and later were introduced, but for the purpose of this blog, we will only discuss Database Server PSUs.

Patch Set Updates are available under the Critical Patch Update program, but unlike traditional CPU patches, PSUs provide a means to deliver security and non-security (i.e. critical bug fixes) fixes bundled together in a tested package. As a result, Database Server customers have a choice when each Critical Patch Update is released: they can opt to receive security fixes only (using the traditional N-apply CPU patches) or they can opt to receive a more comprehensive set of security and non-security fixes (using the Patch Set Update patches). Please note, that for each given Critical Patch Update, customers receive the same security fixes whether they choose to apply a PSU patch or a traditional N-apply CPU patch (in that sense, the traditional CPU patch contains a subset of the fixes available in the PSU patch).

Note that Patch Set Updates are available only for Oracle Database Server 10.2.0.4 and later on platforms other than Windows. Windows Database bundles do however include the same fixes as the Patch Set Updates when they are released.

The below table provides a summary comparison of the PSU patches and traditional N-apply patches available under the Critical Patch Update program.

The application of the Patch Set Update results in the introduction of a new baseline version for the Database Server with consequences in regards to how future patches will be applied on the system when a PSU has previously been installed. Once a PSU has been applied on the system, the recommended method to apply all future CPU program security content is to apply future PSUs. In other words, once a PSU has been applied, it is not recommended to switch back to traditional N-apply patches. While such a switch is possible with assistance from Oracle technical support, it is a complex procedure and therefore is not recommended. However, if previously only traditional N-apply CPU patches have been applied, customers can elect to apply the most current Patch Set Update at any time.

The primary benefit of the Patch Set Updates to customers is that they can receive, in a streamlined fashion, many recommended patches needed to keep their environment secure and operating at top efficiency. This is because the non-security fixes included in each Patch Set Update are designed to address issues related to system or instance-wide outages, severe functionality issues, etc. Non-security fixes that would require application or configuration changes, cause optimizer plan changes or dictionary changes, or contain architectural changes cannot be candidates for inclusion in PSUs.

Another benefit of the Patch Set Updates is the safety they provide to customers. Since the bundle of fixes included in each Patch Set Update is tested together; the risk of regression issues that could be introduced when each fix is applied separately by customers is greatly reduced.

For More Information:
• The Independent Oracle User Group (IOUG) recently posted a replay of a webcast on Database Server security patching with Bruce Lowenthal, Director for Security Alerts for Oracle, and Lois Price, Director for Product Lifecycle Services for Oracle. A significant portion of this webcast was dedicated to exploring the differences between PSUs and traditional CPU patches.
• The Critical Patch Updates and Security Alerts page is located at http://www.oracle.com/technetwork/topics/security/alerts-086861.html
• Note 854428.1 "Patch Set Updates for Oracle Products" is located at https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=854428.1

Hello, this is Eric Maurice again!

Oracle OpenWorld is taking place in San Francisco, on September 19th through the 23rd. As with previous conferences, a number of sessions will focus on Oracle Software Security Assurance topics. These sessions provide attendees with an opportunity to interact with members of the Development and Global Product Security teams. These interactions are extremely useful and rewarding to the Oracle security teams .

Attendees interested in Security Assurance topics may find the following sessions interesting:

• Monday, September 20th : "Recommendations for securely deploying Oracle technology" (Session S316903) with John Heimann and Sven Petersen. In this session, John will discuss Oracle's Secure Configuration Initiative, which is the program that aims at enhancing default configurations in Oracle products to make default deployments more secure. Sven will bring the user's point of view. Sven will discuss Oracle's own internal approach to securely deploying Oracle products, and will talk about some of the "lessons learned" that Oracle's own internal IT organization has experienced.

• Wednesday, September 22nd: "Security governance in a global organization: a case study" (Session 316905) with Chris Gavin and John Heimann. In this session, Chris Gavin, VP for Information Security at Oracle, will discuss some of the challenges in which Oracle operates. Chris will discuss the relationships that exist between IT governance and software Security Assurance, and will provide recommendations around topics including proper vetting of software vendors, etc. John will present the various Oracle Software Security Assurance programs, and how these programs are inscribed in Oracle's own internal governance framework.

• Thursday, September 23rd: "Maintaining a proper security posture with the Critical Patch Update" (Session 316904) with Gaye Stevens and Bruce Lowenthal. This session will be focused on discussing recommendations for deploying Critical Patch Updates (CPUs). Bruce will provide an overview of the CPU program, and will discuss among other things, how to properly interpret the CPU Advisories and make proper patching decisions. Gaye will present the procedures that have been put in place in the Oracle On Demand environment to deal with CPUs. She will also share some of the "lessons learned" that her organization has experienced. Many of the recommendations that will be discussed in this session have been compiled in a recently published technical white paper after interviewing a number of customers and with the input of various Oracle organizations.

For more information:
To register to Oracle OpenWorld, point your browser to http://www.oracle.com/us/openworld/036763

Oracle updated the July 2010 Critical Patch Update documentation to provide the mapping between CVE numbers and Solaris patches. This mapping is also provided in the table below.

We encourage customers to contact secalert_us@oracle.com to ensure that Oracle's updated documentation meets the needs of its customers, particularly as they relate to the CVE to patch mapping.

Your feedback will help Oracle understand the specific requirements of your organization, and for example, will help determine if such mapping should be included in all CPU advisories.

Below is the mapping table between CVE numbers and Solaris patches. This information will also be available in the updated patch availability document referenced in the Critical Patch Update.

You can find the July 2010 Critical Patch Update at http://www.oracle.com/technetwork/topics/security/cpujul2010-155308.html.

Hi, this is Eric Maurice.

On August 11th at 11:00AM Pacific / 2:00PM Eastern, the Independent Oracle User Group (IOUG) will host a webcast on Database Server security patching. Speakers include Bruce Lowenthal, Director for Security Alerts for Oracle, and Lois Price, Director for Product Lifecycle Services for Oracle.

The purpose of this technical webcast is to discuss the various aspects of the Critical Patch Update program (CPU) that are specific to Database Server. The speakers will outline the difference between the Patch Set Update (PSU) and traditional CPU patches. An overview of the CPU program will also be provided.

Update:
Due to technical difficulties, the Database Security Patching webcast, initially scheduled for August 11, 2010 at 1pm CDT has been rescheduled. The new webcast will take place on Wednesday, August 18 at 1pm Central.

You can register again for this event here

For more information:

• Patch Set Updates for Oracle Products [ My Oracle Support Note 854428.1] is located at https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=854428.1 (My Oracle Support subscription is required)


• The Critical Patch Updates and Security Alerts page is located at http://www.oracle.com/technology/deploy/security/alerts.htm