There are currently three major un-patched and published Oracle Database security bugs and all three bugs impact the Oracle E-Business Suite.  All Oracle Applications 11i implementations should review the possible impact on their installations to determine the necessary corrective action.  I don't foresee any of these bugs being fixed before the October 2005 Critical Patch Update.

Here is a quick rundown of the bugs --

1. The previous fixes for a number of SQL injection bugs in standard Oracle Database packages are flawed and can still be compromised.  This is a particularly critical issue in Oracle Applications due to the APPLSYSPUB account and due to the design of the application.
   
2. The View access bypass bug, first inadvertently published by Oracle in April 2006, was not patched in the July 2006 CPU.  This bug can be easily exploited in Oracle Applications.  Any database account with CREATE VIEW system privilege can insert, update, or delete any data where the account has only select permissions.  This bug pretty much blows any data integrity of the application out of the water if you have database accounts with CREATE VIEW privilege.
   
3. An integer overflow exists in the Alter Session statement and can be exploited by the APPLSYSPUB account.  Although, advanced knowledge is probably required to exploit this issue, unless someone publishes a detailed exploit.
   

Integrigy has released an in-depth analysis with possible mitigation steps.

We have released our E-Business Technology Stack Support Matrix for the Oracle Critical Patch Update (CPU) July 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 July 2006 CPU.  The Technology Stack support matrix highlights the differences between certified versions and CPU July 2006 required versions.

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

• No support 11.5.1 through 11.5.6, even though the official desupport date for 11.5.1 to 11.5.6 is July 31, 2006

• 11.5.7 through 11.5.10 rebaselined application technology components are a mandatory prerequisite for the July 2006 CPU

Oracle is using the Critical Patch Updates as a stealth upgrade mechanism to force customers to the latest releases and to a common set of versions.  Ultimately, this probably improves overall customer support as Oracle Support only has to deal with a more finite set of versions and combinations. 

However, we are seeing much pain at some clients as applying the security patches now involves a database upgrade, a Developer 6i patchset, and several application mini-packs, as well as all the security patches for the database, application server, and application.  No wonder most Oracle E-Business Suite implementations are at least 6 months behind on applying the Critical Patch Updates.

http://www.cipher.org.uk/index.php?p=projects/bugle.project

Oracle has decided not to release any security fixes in the July 2006 Critical Patch Update for Oracle E-Business Suite releases 11.5.1 - 11.5.6.  This may come as a shock to more than a few customers since the official Desupport date for 11.5.1 to 11.5.6 is July 31, 2006 (not July 18, 2006).

From E-Business Suite Critical Patch Update July 2006 Note, MetaLink Note 372931.1 -

"Error Correction Support for Oracle E-Business Suite (Oracle Applications) releases 11.5.1 through 11.5.6 will end on 31-Jul-2006 as described in Note 329689.1: E-Business Suite (Oracle Applications) 11.5.1 through 11.5.6 Desupport Notice. Critical Patch Update July 2006 is not planned for these releases. Oracle recommends customers upgrade or migrate Oracle E-Business Suite to release 11.5.7 or later as soon as possible to maintain the highest level of support."

Oracle has been much more aggressive recently in moving customers to newer versions of the Oracle E-Business Suite.  The Critical Patch Updates have become the stealth upgrade stick for many customers, especially in terms of technology stack upgrades.

A frequent topic of discussion after any security assessment or review by auditors is the setting of O7_DICTIONARY_ACCESSIBILITY in Oracle Applications. 07_DICTIONARY_ACCESSIBILITY is a database initialization parameter that controls access to objects in the SYS schema.  It was originally intended to help with migrations from Oracle7 to newer versions where access to data dictionary objects is limited by default. From a pure security perspective, 07_DICTIONARY_ACCESSIBILITY should always be set to FALSE and is a very common security recommendations for Oracle Databases in general.

However, in Oracle Applications 11.5.9 and lower, 07_DICTIONARY_ACCESSIBILITY must be set to TRUE.  This is required for proper functioning of the application and Oracle does not support setting it to FALSE.  In 11.5.10 and higher, 07_DICTIONARY_ACCESSIBILITY should be set to FALSE.  See Oracle Metalink Note ID 216205.1 for more information.

We find in many implementations that have been upgraded to 11.5.10.x, 07_DICTIONARY_ACCESSIBILITY is still set to TRUE.  For all 11.5.10.x implementations, 07_DICTIONARY_ACCESSIBILITY should be set to FALSE.

The APPLSYSPUB account is used by Oracle Applications to initially connect to the database and establish a session.  This account normally should have limited privileges.  However, during our audits the permissions assigned to APPLSYSPUB and PUBLIC are often a security risk and need to be corrected.

Review APPLSYSPUB Privileges

The first step is to review the object permissions granted to APPLSYSPUB by APPS.  These grants are made by "Recreate Grants and Synonyms" in ADADMIN, which executes the script $FND_TOP/admin/sql/afpub.sql. This SQL will create the correct grants, however, it will not remove any unnecessary grants.  Critical Patch Update July 2005 included Oracle Patch 4074867, which removed unnecessary grants in 11.5.1 to 11.5.9.

The following SQL statement will list all the grants from APPS to APPLSYSPUB -

SELECT * FROM dba_tab_privs
WHERE grantee = 'APPLSYSPUB'
AND grantor = 'APPS'
ORDER BY table_name

Compare the results with the list of required grants in the below table.  Remove all unnecessary grants.

Required APPLSYSPUB Privileges (11.5.1 - 11.5.10.2)

insert on fnd_unsuccessful_logins
insert on fnd_sessions
execute on fnd_disconnected
execute on fnd_message
execute on fnd_pub_message
execute on fnd_security_pkg
execute on fnd_signon
execute on fnd_webfilepub
select on fnd_lookups
select on fnd_application
select on fnd_application_tl
select on fnd_application_vl
select on fnd_languages_tl
select on fnd_languages_vl 
select on fnd_product_groups 
select on fnd_product_installations 

See $FND_TOP/admin/sql/afpub.sql for exact list of grants in your implementation and version of Oracle Applications.

A common grant that should be removed is "SELECT on FND_USER_VIEW".  FND_USER_VIEW displays the encrypted foundation passwords, which may be decrypted to reveal the APPS password. FND_USER_VIEW is no longer required in 11i.  As part of the upgrade process, the FNDDOLD.sql should have been executed.  This script is often missed and not executed as part of the upgrade process, therefore, privileges on FND_USER_VIEW must be manually revoked.  It is important to note that some older versions of ADI require FND_USER_VIEW.  See Metalink Note ID 237917.1 for more information.

Review PUBLIC Privileges

Frequently the privileges granted to PUBLIC are incorrect, particularly for custom objects.  The following SQL statement will list all the grants made to PUBLIC for non-system type objects -

SELECT * FROM dba_tab_privs
WHERE grantee = 'PUBLIC'
AND owner NOT IN ('SYS', 'SYSTEM', 'CTXSYS', 'OWAPUB', 'MDSYS', 'ORDPLUG', 'ORDSYS', 'ORDPLUGINS', 'CSMIG')
ORDER BY table_name

A number of packages, types, and Java classes will be listed.  Concentrate on any custom developed objects, especially packages, procedures, or functions.

Custom developed objects - other than views and packages - will reside in custom schemas.  All privileges should be granted to APPS rather than PUBLIC.  It is common during development to grant to PUBLIC rather than APPS to ensure a custom program will work.

The Oracle Applications Security Blog will be an unique analysis and commentary on Oracle related security topics, especially related to Oracle Applications (the official product name is "Oracle E-Business Suite"). Since the Oracle Applications technology stack also includes most of the other Oracle products, I will also cover the Oracle Database, Oracle Application Server, and Oracle development products. My goal is to use this as a forum for some experimentation into presenting security topics in a different way.

I believe the security community generally does a poor job of communicating with the rest of world and does not understand the Oracle products. I am looking to borrow techniques and ideas from other disciplines, like economic forecasting, to provide information that will help you to make better decisions and plans related to the security of your Oracle implemenations.

Please feel free to e-mail me any comments, suggestions, or other feedback. As this is an on-going "project" (aka experiment), I am more than open to feedback either positive or negative.

- Stephen Kost