We have updated our free Oracle Database Listener Security Check tool that analyzes security of the Oracle Database TNS Listener to identify potential security issues.

Two new features have been added from upcoming changes to our AppSentry security auditing tool -

• Checks all the entries in a tnsnames.ora file for four security configuration issues in the database listener
  

• Generate TNS entries and JDBC connect strings (6 different ways) for enumerated SIDs

The AppSentry Listener Security Check Tool is available for download at -

http://www.integrigy.com/security-resources/whitepapers/lsnrcheck-tool/view

Two weeks after the initial release of the October 2006 Critical Patch Update (CPU) Advisory, Oracle added information about the Oracle Database 9.2.0.8 being vulnerable and about a patch being available in the future.  The 9.2.0.8 patch release date keeps getting pushed back and is now scheduled for December 22 on Unix/Linux and December 15 for Windows (5 days ago).

The Oracle E-Business Suite Note for the CPU (Metalink Note ID 391564.1) has not been updated to show the required 9.2.0.8 patch.  If you have upgraded to 9.2.0.8, then you need to apply the CPU security patch when it becomes available as it corrects a number of high-risk vulnerabilities.

We have updated our free Oracle Database Listener Security Check tool that analyzes security of the Oracle Database TNS Listener to identify potential security issues.  The tool performs four basic checks for the Database Listener in a simple and user friendly way - (1) is a listener password set, (2) is ADMIN_RESTRICTIONS set, (3) is logging enabled, and (4) is LOCAL_OS_AUTHENTICATION enabled for Oracle 10g.  It is a single executable that can be run from any Windows XP/2000 PC, requires no Oracle client install, and can be run from a USB key.

The following enhancements are in the new version -

• Fully compatible with Oracle 10g (10.1 and 10.2)
• New Oracle Applications 11i check for database and FNDFS listeners
• New enumeration of all instances for a listener
• Saves history of servers and ports for easy access

The AppSentry Listener Security Check Tool is available for download at -

http://www.integrigy.com/security-resources/whitepapers/lsnrcheck-tool/view

The inherent weakness of the Oracle Applications 11i user password algorithm is a topic that every so often gets some attention.  It bubbles up and then is largely forgotten by most.  However, the issue doesn't go away and is very much alive today even in 11.5.10.2.  See the references at the end of this post for a little history of the topic.  This password weakness (along with the APPLSYSPUB database account) is really a hold-over from client/server and is an inherent design flaw in the current architecture of Oracle Applications.

Many people are missing two critical issues with the Oracle Applications 11i user password encryption -

• The encryption is basically two way - (1) if you know any username/password you get the APPS password or (2) if you know the APPS password, you get any user's password.  I can see about potential fraud if you know another user's password, but the APPS password is the key to the kingdom.  Most likely someone shouldn't have the necessary privileges in production to obtain this information, but often the user's passwords are in cloned instances like development.
  
• Since the decryption routine is a Java class, it is actually easy to create a Java application that calls the decrypt method.  Simply put in a username, password, and encrypted password, out comes the APPS password.  Put in a username, APPS password, and encrypted password, out comes the user's password.  No need to even have access to a database to run the decrypt.
  

Improving the Oracle Applications 11i password algorithm is a complex change and I don't expect Oracle to fix it in the foreseeable future.  Hopefully in Release 12, a strong hash algorithm will be implemented and the APPLSYSPUB database account will no longer exist.

In the meantime, here are a few recommendations to at least improve the security of the user passwords.  The goal is to limit access to the FND_USER table and the encrypted passwords, just as should be done with DBA_USERS.

• Verify APPLSYSPUB does not have SELECT privileges on APPS.FND_USER_VIEW.  This is especially an issue with instances that were upgraded from 11.5.6 and prior.  This view is not required by APPLSYSPUB, except for old versions of ADI.
  
• Change the passwords for all Oracle Applications 11i seeded accounts (SYSADMIN, GUEST, WIZARD, APPSMGR, etc.) even though these accounts may be already disabled.  At the same time, make sure all accounts except for SYSADMIN and GUEST are disabled (note a few accounts may be required by a specific module).  See Metalink Note ID 189367.1 for the most up to date list of seeded user accounts.  Be sure to change the GUEST password and follow the solution in Metalink Note ID 396537.1 for details on changing the password and check that the password was also changed in the System Profile Option "Guest User Password".  For years clients have questioned why we recommend always changing the seeded account passwords even though the accounts may be disabled -- this is the reason why.
• Create all new user accounts with strong and unique passwords.
• Limit access to the APPLSYS.FND_USER and APPLSYS.FND_ORACLE_USERID tables by all non-DBA accounts including any query-only accounts.  Often an APPSREAD or similar database account is created for support purposes or end-user query use.  These accounts tend to be created with SELECT ANY TABLE system privilege, which allows them access to FND_USER.

Cloning presents a security issue with Oracle Applications since sensitive information like passwords are in the cloned instance.  This applies to both FND_USER as well as DBA_USERS since weak database passwords can be easily cracked (see the tool orabf).  The challenge with cloning is that there may be multiple cloned instances with different uses and varying levels of access.  Often the development instance is wide-open to all developers and the APPS password is distributed.  Support instances may be frequently cloned, contain sensitive information, and be accessed by end-users.  Broadly changing passwords all passwords in DBA_USERS and FND_USER usually is difficult to accomplish, but with the security weaknesses of both the application and database passwords changing all the passwords is strongly recommended for every cloned instance.

References about the Oracle Applications 11i Password Weakness

May 2002 - Martin Schlafer and Michael Ackerman of Answerthink were the first ones to really document this issue in their OAUG paper "Oracle Unbreakable? Part I: Ten Hot Security Spots in Oracle Applications 11i" presented at the Spring 2002 OAUG Conference in Toronto.  The paper is available for download from the OAUG Conference Paper Archive (OAUG membership required).  They highlighted both the password weakness, as well as, the fact that anyone could download all Java JAR files from any Oracle Applications implementation through the web server.  The ability to download the JAR file isn't really much of an issue since it is fairly easy to obtain and every Oracle Applications 11i implementation in the world uses the same algorithm.  Although, Oracle has limited the downloading from the web server of the core JAR files to just those used by JInitiator.

November 2005 - http://www.erp100.com/viewthread.php?action=printable&tid=1592 (Simplified Chinese -> English Translation)  (Sidenote: I would like to know what in Chinese ends up as translating to this - "We know tuberculosis Oracle database provides a common account")  This post has sample PL/SQL procedures to crack a password.

May 2006 - http://521102yz.itpub.net/post/5095/84876 (Simplified Chinese -> English Translation) - Report of the above information

December 2006 - http://johanlouwers.blogspot.com/2006/12/oracle-applications-passwords.html

With the advent of legislative mandates like Sarbanes-Oxley (SOX) and the Health Insurance Portability and Accountability Act (HIPAA), the security and auditing of Oracle Databases has become much more of a priority for most organizations. A common solution has been to implement an Oracle-aware Intrusion Detection System (IDS) or auditing product to address these legislative mandates and increased auditor scrutiny. Integrigy has released a new whitepaper paper that looks at a number of techniques that may be used to evade such Oracle intrusion detection and auditing solutions, especially signature-based solutions.  It is actually very easy to evade a signature-based Oracle IDS solution.

Organizations that have implemented network-based IDS and auditing solutions for their Oracle databases should carefully review the actual effectiveness of these solutions.

Whitepaper: Evading Network-Based Oracle Database Intrusion Detection Systems

In a follow-up to my previous post regarding mystery patches for 9.2.0.8 in the October 2006 Critical Patch Update, the CPU advisory was updated to include information about 9.2.0.8.  However, the patches for 9.2.0.8 are still not available and have an anticipated release date of December 15, 2006 (note: the initial release date was November 15, 2006).

The initial release of the October 2006 CPU did not include any references to 9.2.0.8 as being vulnerable or requiring patches.  Oracle did not update the advisory until October 31st.  So if you evaluated your internal risk and identified databases requiring patches prior to October 31st, you will need to reevaluate all your 9.2.0.8 databases.

The following vulnerabilities were updated to include 9.2.0.8 - DB09, DB13, DB14, DB15, and DB17.  DB09 is the View bug, which is serious.  DB13 and DB17 are SQL injection bugs in standard Oracle Spatial packages or triggers.  DB14 and DB15 are SQL injection bugs in XDB packages.  All of these SQL injection bugs allow a database account with limited privileges the ability to execute SQL fragments as a privileged database account like MDSYS.

A new attack vector for the Oracle Database has been identified related to exploiting DBMS_SQL cursors that have not properly been closed.  The name for this type of attack is "Dangling Cursor Snarfing."  David Litchfield's paper on the topic can be found here.

Exploitation of this type of vulnerability is limited and requires ALL of the following conditions -

1. Direct SQL*Net connection to the database with proper authentication
2. Cursor executed in a package or procedure with Definer Rights
   
3. Use of dynamic SQL via DBMS_SQL
4. Can not alter the parsed SQL statement and can only change bind variable values
5. The cursor is not properly closed in a logic branch or in the event of an exception

The DBMS_SQL package is typically only used for dynamic SQL statements that either are generated at run time (e.g., complex searches) or are dynamically setting the table/view name or column names.  These typical uses of DBMS_SQL do not lend themselves to much of an opportunity for an attacker or a significant security vulnerability.

• There are around 90-120 Standard Oracle Database Packages in Oracle 9.2 and 10.2 that use DBMS_SQL and some of these packages may be vulnerable to this type of attack.  The Oracle code in most places is actually good about making sure cursors are closed even when an exception occurs due to performance concerns.  Without an extensive code review, it is difficult to determine which packages may be vulnerable since Definer Rights are "inherited" from the calling package.  There probably was a mad scramble by security researchers to find any such vulnerabilities and most all should have been reported to Oracle by now.  My assumption is that a couple of package procedures or functions have low risk type issues, but nothing major.
  

• Oracle Applications 11i has very few packages with Definer Rights and none of the packages with Definer Rights use DBMS_SQL.  Therefore, there is no risk associated with Oracle Applications 11i.

Based on the conditions for a vulnerability to exist and the type of SQL statement that could be exploited, this attack vector is practically a non-issue.  Yes there will be a few instances of it found in some applications, but in reality not much will be found overall.  You should be much more concerned about SQL injection issues with any use of the DBMS_SQL package than about dangling cursor snarfing.

The media and bloggers did seem to jump on the bandwagon and widely reported the existence of this new attack vector.  It seems that Microsoft is no longer the "bad security poster boy" and Oracle is taking the majority of criticism the past few years, even though this particular attack vector is more related to poor programming than an inherent flaw in the database.

A security research firm based in Argentina, Argeniss, had announced a plan to publicly disclose an unfixed Oracle Database security bug every day for a week in December - "The Week of Oracle Database Bugs."  A disclosed unpatched security bug is referred to as a 0-day (or zero day).  Argeniss' motivation is "to demostrate Oracle isn't getting any better at securing its products."

Yesterday, Argeniss announced that they have suspended their plan "due to many problems."  It is unclear as to why they have suspended it, but based on the publicity generated I think "postponed" may a more operative word.

This event highlights two key points -

• There are hundreds of unpatched security bugs in the Oracle products, thus the Critical Patch Updates (CPUs) will continue for the foreseeable future.  You should plan for the same type of complex and bulky CPUs until at least April 2008.  Since the CPUs will keep coming, all organizations need to have a well defined and executable security patch process in place in order to deal with the CPUs in an efficient and timely manner.
• Most organizations don't apply the CPU patches for at least 45-120 days after release, therefore, usually there are 20-60 unpatched security vulnerabilities in an average Oracle database.  For about 25% of the fixed database vulnerabilities in a CPU, detailed and workable exploit code is released.  The release of seven new zero-day vulnerabilities really doesn't impact much the security of most organizations as there are already a significant number of unpatched vulnerabilities.  Also, seldom are the Oracle Database vulnerabilities remotely exploitable without proper database authentication.  Organizations should not be overly reacting to this event rather a comprehensive plan and procedure should be put in place to apply CPU patches in a timely manner and to harden all databases and application, which will improve security much more than overly reacting to these type of public disclosures.

Oracle Database session information includes database user name, operating system user name, host, terminal, IP address, module, program, timestamps, session ID, and other details. These values are critical to auditing and identifying the actual end-user. Many of the database session values can be “spoofed” by an attacker either to mask their true identity or to circumvent security and auditing measures.  It should come as no shock to anyone that many of these values can be spoofed since this fact has been widely discussed for years.

Even though experienced database administrators know about the ability to spoof these session values, Integrigy security consultants consistently find programs and applications relying on “spoofable” session information within database logon triggers and in database auditing. With the emphasis on auditing in recent years due to legislative requirements, we are actually seeing this issue much more often now than three years ago. This is an auditing implementation issue found especially in large complex ERP or CRM implementations where auditing has been configured to satisfy Sarbanes-Oxley (SOX), HIPAA, Payment Card Industry Data Security Standard (PCI DSS), or other legislative and regulatory requirements. Due to the complexity of an application and large transaction volume, often some level of filtering must be enabled to sift through the enormous amount of audit data generated. In many cases, the filtering is applied to differentiate between normal transaction processing and anomalous transactions by either an attacker or a privileged user (i.e., Super User or DBA) when auditing has been enabled due to SOX requirements.

To address this issue we have published a new whitepaper which is a comprehensive examination of the key database session elements and the ability to spoof these values – there is neither new information nor new security vulnerabilities discussed in this paper. Much of the information has been previously discussed to some extent in Oracle-related security mailing lists and other forums. The goal of the paper is to build awareness of this issue since Integrigy consultants performing security assessments consistently see absolute reliance on “spoofable” values in auditing and security solutions.

The paper looks at four common stores and uses of database session information related to security and auditing: (1) V$SESSION view, (2) SYS_CONTEXT function, (3) Database Session Auditing, and (4) Fine Grained Auditing (FGA). The V$SESSION view contains one row per current database session. The SYS_CONTEXT function returns information regarding the current database session and is often used with database logon triggers. Database session auditing (AUDIT SESSION;) records all database logons and logoffs. Fine Grained Auditing is used to audit SQL statements executed for specific database objects and can be configured based on columns or other criteria.

Whitepaper: Spoofing Oracle Session Information

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.

Oracle has finally certified the use of Advanced Security Option/Advanced Network Option for encryption of SQL*Net traffic between the database and application servers.  This certification had been promised for several years.

The Advanced Security Option (ASO) is an optional component of the Oracle Database and is an extra cost.  Advanced Networking Option (ANO) is the previous name of ASO in Oracle 8.0.x, which is also utilized in an Oracle Applications 11i configuration since Forms, Reports, and Concurrent Manager still use an 8.0.6.3 ORACLE_HOME.

This certification and encrypting of SQL*Net traffic is only relevant for highly secure implementations that require encryption of all network traffic.  The application servers and database should be solely contained in a secure data center, so encryption of this traffic only provides marginal benefits.  Of more concern is direct SQL*Net connections from application servers deployed in a DMZ and for administration (DBA's), ad-hoc querying, interfaces, and other direct SQL*Net connections.

Oracle has only certified the use of RC4 (40 or 128) rather than DES, 3DES, or AES.  RC4 is the best performing ASO encryption algorithm.  Implementations that want to comply with FIPS 140 are out of luck as only RC4 is supported.

Performance should be tested prior to implementing encryption in a production environment as the Forms SQL*Net traffic is "chatty" and could impact CPU utilization on both the database server and application servers, since RC4 is best performing for large packet sizes.

The biggest challenge to implementing encryption is the requirement of 11.5.10 and 11i.ATG.PF.H RUP3, where RUP3 is a minimum requirement for applying Critical Patch Updates.  Also, it does not appear that the AutoConfig templates support the changes to the SQLNET.ORA file for the 8.0.6.3 ORACLE_HOME, so these changes will have to be reimplemented each time after running AutoConfig.

Organizations with stringent security requirements would benefit from a limited deployment of encryption of all direct SQL*Net traffic from outside the data center, including application servers deployed in the DMZ.  This configuration would encrypt the most at risk traffic and eliminate any potential performance issues with encrypting all application server traffic.  ASO can be configured using the ACCEPTED and REQUESTED parameters to allow for some client connections to be encrypted.  This will not require encryption, but properly configured clients will then use encryption.

References:

Metalink Note ID 391248.1 "Encrypting EBS 11i Network Traffic using Advanced Security Option / Advanced Networking Option"

As I have previously discussed (here and here), Oracle is requiring recent ATG rollup patches to be installed as prerequisites for the Critical Patch Updates.  The ATG_PF rollups are generally released every 6 months.  For ATG_PF.H the following rollups have been released --

CU1 = February 2005
CU2 = July 2005
RUP3 = February 2006
RUP4 = August 2006

The rollup patches are latest code for AOL, Alerts, Oracle Applications Framework, Oracle Applications Manager, Workflow, XML Gateway, User Management, and CRM Technology Foundation to name just a few of the modules.  Also included are recent AutoConfig template files.  These are significant patches and need to be thoroughly regression tested.

RUP3 is the minimum requirement for the October 2006 Critical Update Update.  Starting with the July 2007 CPU, you must be running at least RUPn-1 (where n is the current RUP).  The January 2007 and April 2007 CPUs most likely will require at least RUP3.

Based on timing, this means to apply CPU patches in the future, you will have to at least to have tested and applied a major ATG_PF patch in previous 8 months.  The rollups also require the latest AD patchset (e.g., AD.I.4) be applied and the database to be at least 9i.  For implementations running Oracle Application Server 10g integration, the latest integration patches must be applied.

Many implementations do not apply technology patches on a regular basis, but require CPUs to be installed within 60-180 days.  Security sensitive organizations have to make sure their internal release and upgrade timelines are in sync with the Oracle RUP releases.  Annual upgrade schedules probably have to be abandoned in favor of quarterly or semi-annual technology upgrades.  At least every 6 months, an ATG RUP, AD minipack, and database upgrade are probably required moving forward.

Our recommendation is still to prioritize and install the latest cumulative database security patch within 30 to 60 days, which corrects the largest number, most critical, and easiest to exploit vulnerabilities.  Feedback from our clients show very few problems with the database security patches and some companies are moving to minimal testing for these patches.  Oracle Applications patches should be addressed next and coincide with a quarterly or semi-annual technology upgrade schedule.  Application Server patches are often not as critical as the database and application patches, therefore, these patches should be prioritized last for non-Internet implementations.