Oracle has adopted the Common Vulnerability Scoring System (CVSS) as its standard for communicating the severity of security vulnerabilities in its products.  The critics have already jumped on Oracle for "manipulating" the CVSS scores for the October 2006 Critical Patch Update (CPU) (story here).

First and foremost, I applaud Oracle's decision to adopt CVSS and jettison the old proprietary system.  As more large organizations begin using CVSS, the metrics will become more widely understood and discernible.

The use of CVSS for rating the severity of security vulnerabilities in Oracle products is far from perfect and the resulting scores must be understood to correctly comprehend the risk associated with the patched vulnerabilities.  There are three aspects that need to be considered regarding Oracle's usage of CVSS - (1) the CVSS standard itself, (2) Oracle's implementation of CVSS, and (3) customers interpretation of the vulnerability scores.

The CVSS Standard and Oracle Products

CVSS was clearly developed by network and system security folk (which is probably appropriate considering its purpose) as demonstrated by the heavy weighting on the network device and operating system rather than a metric where network device, operating system, database, and application share a similar weighting.  The CVSS Confidentiality, Integrity, and Availability values are None, Partial, and Complete.  For a Complete score in any category, the entire "system" must be completely compromised, not just the entire database or entire application.  Thus, the ability for an attacker to "own" the entire database and not the Unix root account will only give you a Partial.  Similar is the case of an attacker able to compromise the Oracle Application Server and fully manipulate the Oracle HTTP Server (Apache) to replace or change any files -- only a Partial.

So fundamentally, an application or database vulnerability can really only score up to a 7, whereas a vulnerability in a network router or server operating can score a perfect 10.  You still lost all your data, but it was only a 7.

The scores become even more whacked out when you only look at one category (Confidentiality, Integrity, or Availability).  If you can easily compromise just the Confidentiality or Integrity of the entire database, remotely, and without authentication, then the score is a 2.3.  Both the Confidentially and Integrity of the entire database would only get you a 4.7. 

My first thought was that if you can compromise both the Confidentiality and Integrity of the entire database, you would most likely be able to affect the Availability and get a score of 7.  Not true.  Of the 11 vulnerabilities in the October 2006 CPU marked Partial+ for both Confidentiality and Integrity, 8 are marked as None for Availability for a maximum score of 4.7 (since authentication is required really only a 2.8).

Of all the database vulnerabilities fixed by Oracle, very few allow you to directly compromise data in the database without authentication.  Usually you have to leverage multiple vulnerabilities or perform other actions once the operating system is compromised (neither Oracle or CVSS take the "blended threat" into account).  This being the case, the maximum scores are even lower for almost all database vulnerabilities.  The realistic maximum score for a database vulnerability is really only 4.2.

Oracle and CVSS Metrics

As shown above, the issue is not with Oracle, but with the way the CVSS metrics work with databases and applications.  Based on a pure interpretation of the CVSS standard, all the Oracle score look appropriate.  I really can't fault Oracle for using CVSS or accuse them of adopting it as a marketing tool because of the low scores calculated for the database and applications, since it is really the only standard of its kind and is supported by the Department of Homeland Security.

To account somewhat for this issue (I have to give Oracle some credit on this one), Oracle has slightly modified the CVSS values (see Metalink Note ID 394487.1) to include Partial+, which means a full compromise of the component (i.e., the database).  However, Partial+ does not change the metric in any way.  Oracle does suggest you change the Partial+ to Complete and recalculate the vulnerability score yourself.  A standard is a standard and should be implemented the same way by everyone (or you end up with something that looks like UNIX).

Oracle has always ignored "blended threats" and only looks at "each security vulnerability in isolation."  With all the buffer overflows and SQL injection bugs in standard Oracle Database functions, SQL injection is an excellent attack vector and it is much easier to exploit these known vulnerabilities than attempting traditional SQL injection methods.  However, "blended threats" are not included in the CVSS score in any way nor is the possibility researched by Oracle.

Customer Usage of CVSS Metrics

Customers really to need to fully understand what the CVSS scores mean and that the scores are not directly comparable to network devices or operating systems scores.  When viewing the scores, I would recommend you use the following guidelines for maximum scores.  These maximums represent a possible complete compromise of the database, server, or application -

Oracle Database = 4.2
Oracle Application Server = 4.7
Oracle E-Business Suite = 4.7

These are the realistic maximum scores attainable for almost all Oracle vulnerabilities in these products.  Yes, it is possible to have higher scores, but it will be a rare event.  The risk matrices need to be reviewed for all vulnerabilities marked with "Partial+", which represent a complete compromise of the product (see Metalink Note ID 394487.1).

Another major issue for Oracle E-Business Suite customers, there is no direct or official mapping of vulnerabilities to patches.  Therefore, the CVSS scores can not be readily used to prioritize patches.  I hope in future Critical Patch Updates, Oracle will provide this mapping.

Oracle has updated the white paper "Best Practices for Securing Oracle E-Business Suite version 3.0.4" Metalink Note ID 189367.1.  The major changes to the document include -

• Added the new Oracle Applications 11.5.10 application accounts AME_INVALID_APPROVER and XML_USER to the list of accounts that require passwords changes and that should be disabled. (p. 21)
• Additional instructions for securing the APPLSYSPUB database account. (p. 52)
  
• Added the forms FNDFFMDC ("Define Descriptive Flexfield Segments") and FNDFFMVS ("Define Flex Value Sets")to the list of forms that accept SQL statements. (p. 47)
  

If you already implemented all the recommendations, you should look at the following -

• Check for the application accounts AME_INVALID_APPROVER and XML_USER and disable them and change the password if they exist.
• Review access to the forms FNDFFMDC and FNDFFMVS.  I have not reviewed what responsibilities usually have access to these forms.  Since they involve Flexfields, these two are different than the other AOL forms on the restricted access list and may require some work to secure.

If you have not implemented the "Managed SQL*Net Access Feature" in 11.5.10, then direct SQL*Net access to the database and access to the APPLSYSPUB database account is your most significant security hole.  The most significant issue is that many of the security vulnerabilities fixed in the Critical Patch Updates can be easily exploited (see page 3 of our analysis).  However, Integrigy has previously not recommended changing the APPLSYSPUB password because of known issues and since the password is often displayed or could be easily obtained.  Rather we have pushed clients to make sure the APPLSYSPUB account is as secure as possible (see here).

Almost all the disclosure issues with the APPLSYSPUB password have been corrected in 11.5.10.2 and the issues with changing the password seem to have mostly been resolved.  There is a procedure on page 52 that describes how to change the APPLSYSPUB account and the required patches to make sure AutoConfig changes the password in all the correct places.

If you analyze Oracle's Critical Patch Update for October 2006 Advisory and look for any vulnerabilities affecting the Oracle Database version 9.2.0.8, you will see in the "Oracle Database Risk Matrix" that there are no vulnerabilities for 9.2.0.8.  In the "Supported Products and Components Affected" section, 9.2.0.8 is not listed.  In the initial release on October 17th of the "Critical Patch Update Availability for Oracle Server and Middleware Products" (MetaLink Note ID 391563.1), for 9.2.0.8 on Unix/Linux and Windows was listed as "not applicable".

So then way did Oracle Support on October 19th change the patch availability for 9.2.0.8 and list a patch being available for 9.2.0.8 on November 15th?

Oracle first fixes security bugs in the current code-line (in this case 9.2.0.8) and then backports the fixes to previous versions.  It is not uncommon for a recently released patchset to include all the CPU security fixes, especially since Oracle takes 6-24 months to fix most bugs.  9.2.0.8 was generally released for the major operating system the week of August 21st.  In the case of the 5 publicly announced bugs discovered by Red Database Security, 4 were reported to Oracle in November 2005 (DB01, DB04, DB10, DB15) and 1 in April 2006 (DB13).  Clearly enough time for Oracle to fix these bugs and include them in the August release of 9.2.0.8. 

So at this point it is unclear what is actually fixed by the 9.2.0.8 CPU patch.  9.2.0.8 already includes all the previous CPU patches, therefore, what has been discovered missing from 9.2.0.8?

For planning purposes be sure to include 9.2.0.8 on your list of to be patched databases.

Special thanks to Matt Penny for pointing out the change in status for 9.2.0.8.

We have released our quarterly Oracle E-Business Suite Impact analysis for the Oracle Critical Patch Update (CPU) October 2006.  This analysis looks at the CPU from an Oracle E-Business Suite perspective and provides additional details on the fixed vulnerabilities and a patching strategy for the Oracle Database, Oracle Application Server, Oracle Developer 6i, Oracle JInitiator, and Oracle Applications 11i.

This quarter is the same as the previous seven with many patches and long hours in order to get all the security patches applied in a timely manner.  The biggest challenge for many will be the mandated requirement of ATG_PF.H RUP3 or RUP4 for all 11.5.10 to 11.5.10 CU2 implementations.  On the positive side, most of the Oracle Applications patches are for security weaknesses (like storing some ancillary passwords in plain-text) rather than critical and readily exploitable security vulnerabilities.

The Oracle E-Business Suite Impact analysis is available here.

As with previous Oracle Critical Patch Updates (CPU), a number of the database patches have not yet been released.  Major versions and operating systems are on the list.  Oracle has already "desupported" a number of versions by stealth through not supplying security patches (e.g., 9.2.0.1 - 9.2.0.5).  Customers really need to push Oracle to get the patches out on-time, especially for major releases and operating systems.  I can see not having z/OS and Linux on Power ready, but Unix and Linux?  Most of the missing patches are backports on mainstream operating systems.

The following is a list of missing patches for major platforms -

• 9.2.0.6 = Unix, Linux, and Windows = End of October
• 10.1.0.4 = Unix, Linux, and Windows = End of October
• 10.2.0.2 = Windows = October 20th

Since Oracle recommends customers apply the database patch first, this will delay a number of customers in applying the CPU patches or force some quick upgrades to the newest patchset.

We have released our E-Business Technology Stack Support Matrix for the Oracle Critical Patch Update (CPU) October 2006.  The supported technology stack versions required by Oracle’s Critical Patch Updates (CPU) may be different from the certified technology stack versions.  A prime example is that 9.2.0.5 is certified for Oracle Applications, but is not supported by the October 2006 CPU.  The Technology Stack support matrix highlights the differences between certified versions and CPU October 2006 required versions.

The two most significant changes to the technology stack support matrix for the October 2006 CPU are –

• 8.1.7.4 is no longer supported for 11.5.7 or 11.5.8, thus no CPU security patches for 11i
• For 11.5.10.x, ATG_PF.H RUP3 or RUP4 is a mandatory prerequisite

• 11.5.7 through 11.5.9 rebaselined application technology components are a mandatory prerequisite
  

The E-Business Technology Stack Support Matrix is available here.

Oracle has released the Critical Patch Update (CPU) for October 2006.  101 new vulnerabilities across all Oracle products are fixed in this CPU of which 45 are remotely exploitable.  The overall number is high as compared to previous CPUs, but includes a similar number of database and application server vulnerabilities.  The spike is due to 35 vulnerabilities in Oracle Application Express (formerly HTMLDB).

A preliminary analysis shows, with the exception of the Oracle Application Express vulnerabilities, the patched vulnerabilities are similar to previous CPUs and there is nothing noteworthy.  Most troubling is that Oracle needs to fix 10-30 vulnerabilities in the Oracle Database every quarter.  The number of new vulnerabilities and reported unpatched vulnerabilities does not seem to be shrinking.

It appears, but we have not yet confirmed, that OHS01 is the mod_rewrite vulnerability (CVE-2006-3747) reported and fixed by Apache in July.  If you are using mod_rewrite with 9.0.4.1 or higher, you may want to review the configuration conditions where this vulnerability is exploitable.

For the Oracle Database, the same database versions are supported as the July 2006 CPU and there are no patches required for 9.2.0.8 or 10.2.0.3. [CORRECTION: Oracle added on 19-Oct-06 that a patch will be available for 9.2.0.8 in mid-November.]

For the Oracle Application Server, CPU patches are not available for 1.0.2.2 as a standalone product and no patch is required for 10.1.4.0.1.

For the Oracle E-Business Suite 11i, as I have previously discussed, the major change is that ATG RUP3 or RUP4 is required to install any of the October 2006 CPU patches.

All customers using Oracle Application Express (HTMLDB) 1.5 to 2.0 for application development should quickly evaluate the impact these new vulnerabilities may have on their applications, especially those accessible via the Internet.

No new Oracle Collaboration Suite (OCS) vulnerabilities.

No new Oracle Enterprise Manager (OEM) vulnerabilities.

Although, OCS and OEM are affected by database and/or application server vulnerabilities.

With this CPU, Oracle has introduced several documentation changes.  The most subtle (and unannounced) is that Oracle actually posted the total number of new vulnerabilities (101) clearly at the top of the documentation -- this will eliminate the miscounting seen in news reports with previous CPUs.  The new executive summaries are very high level and provide no real details about the vulnerabilities.  The inclusion of the CVSS matrices and base scores does provide a more standard approach to identifying the risk of each vulnerability.

We are working on our impact analysis for the Oracle E-Business Suite and should have it available in the next day or so.

History:
17-Oct-06 - Initial Version
26-Oct-06 - Added information on 9.2.0.8 patch being available mid-November

The Oracle Global Product Security team has announced some new changes to Oracle's quarterly Critical Patch Update (CPU) documentation. Organizations face a huge challenge in attempting to prioritize and determine the impact of each CPU, especially in complex application environments (like Oracle Applications 11i) where multiple patches must be applied.  The new changes to the CPU documentation are aimed at providing additional information to help organizations prioritize CPU patches.  These enhancements may satisfy a few Oracle critics, but most are looking for more detailed information on each vulnerability.

There are three enhancements for the October 2006 CPU -

1. A high-level executive level summary - This will be interesting to read as Oracle intends it to be suitable for "executive management and other non-IT groups."  With the large number of vulnerabilities in each CPU, it will be difficult to provide much detail. Most likely, the summary will only highlight the most critical vulnerabilities.
2. Remotely exploitable vulnerabilities highlighted - These vulnerabilities could be determined by carefully analyzing the CPU risk matrix, but now will be clearly marked.  I am not sure how much of a difference this will make for a few reasons - (1) few of the Oracle Database security bugs are remotely exploitable (usually SQL*Net related), almost always authentication is required to exploit the vulnerability, (2) many of the Oracle Application Server bugs are remotely exploitable, and (3) the database and application server patches are all encompassing, so it is not possible to patch a single vulnerability.  This will be most important for Oracle E-Business Suite patches, which are individual patches.
3. Common Vulnerability Scoring System (CVSS) Base Metric Group score for each vulnerability - CVSS is an attempt to "standardize" the definition of a vulnerability's severity.  I am not sure how organizations will use the CVSS scores (e.g., if it is a 3.0 or higher we patch).  It will be interesting to see how useful the CVSS scores are and how organizations use them.  A nice calculator is available here to see an example score.  You can use the calculator to determine the "Environmental Metric" and "Temporal Metric" for your environment.

I see several potential issues with the documentation enhancements -

• A major emphasis is placed on remotely exploitable vulnerabilities.  DBAs are looking for any excuse to delay or not apply CPUs due to the complexity and effort required, so no remotely exploitable vulnerabilities in a CPU may be all some DBAs need to postpone this quarter's security patches.  By emphasizing remotely exploitable vulnerabilities, the totality of the seriousness of each CPU may be diminished.  Since all Oracle Databases should be protected by a firewall from the Internet, the most significant threat is from internal users who most likely will have a database account or may be able to access the database through an application proxy account (i.e., think APPLSYSPUB for Oracle Applications 11i).  Also, SQL injection is a common attack vector for Oracle Databases.
  
• The CVSS metric has a heavier weighting toward "Authentication Not Required" and equally weights for Confidentiality, Integrity, and Availability impacts.  Thus as with the above emphasis on remotely exploitable vulnerabilities, a few vulnerabilities will receive significantly higher scores and focus.  Calculating some of the scores for the July 2006 CPU, I don't see an immediate benefit from the scores in helping to prioritize the CPU patches.  They are a nice to have, provide a metric for senior management, and may be useful in comparing to other vendor patches (e.g., Microsoft), but I don't see the scores impacting the patching decision or process.
• The Oracle E-Business Suite 11i patches are not linked to a specific vulnerability in the CPU documentation, so the CVSS metric information is not useful for these patches.  Hopefully, Oracle will provide the mapping, so customers can actually prioritize these patches.
• Oracle's stance with the CPUs is that you need to apply all the patches ASAP.  I don't see this changing, therefore, the bias of the CPU documentation will be toward the severity of vulnerabilities and the need to patch.  Only when Oracle is advising customers to prioritize specific patches due to severity (such as apply the Application Server patch now and then apply the Database patch during the next downtime) will any of this information be useful.  In complex application environments, like Oracle Applications 11i, it is very difficult to regression test and apply all the patches at once.

Overall, the changes to the CPU documentation will provide most organizations only minor benefits.  These enhancements may help mid-level management to better sell the need to apply the CPUs in a timely manner to top executives.  Hopefully as Oracle improves the CPU process and documentation, Integrigy will no longer have to publish our own analysis of each CPU.

Oracle has updated the "Integrating Oracle E-Business Suite Release 11i with Oracle Internet Directory and Oracle Single Sign-On" whitepaper from build 3.2 to build 4.0.  This whitepaper is a detailed description of implementing Single-Sign-On for Oracle Applications 11i.  It is one of the more useful Oracle documents, especially since it covers multiple scenarios and provides details on limitations.  The scenarios include Oracle-only implementations as well as using third party identity management solutions.

The whitepaper corresponds with Metalink Note ID 233436.1 "Installing Oracle Application Server 10g with Oracle E-Business Suite Release 11i", which is the actual installation instructions.

For organizations already running a single sign-on solution (e.g., Microsoft Active Directory, SiteMinder, iPlanet), integrating Oracle Applications 11i can provide benefits in terms of single sign-on and user terminations.  However, the current LDAP integration is limited and does not provide meaningful user provisioning or synchronization.  The solution requires the implementation of Oracle Internet Directory regardless of the third party LDAP solution, so beware of additional hardware, software, and implementation costs.