Stephen Kost's E-Business Suite Security Blog
Just when you thought the Oracle Database world was getting safer, Oracle will be releasing fixes for 32 database security bugs on Tuesday, October 14th. This is in stark contrast to the previous twenty-five quarters where the high was 16 database bugs and average per quarter was 8.2 database bugs. For the previous two years, the most database bugs fixed in a single quarter was six.
In addition to the 32 database security bugs, there are a total of 155 security bugs fixed in 44 different products.
Here is a brief analysis of the pre-release announcement for the upcoming October 2014 Oracle Critical Patch Update (CPU).
- There are 32 database vulnerabilities; only one is remotely exploitable without authentication and 4 are applicable to client-side only installations.
- Since at least one database vulnerability has a CVSS 2.0 metric of 9.0 (critical for a database vulnerability), this is a fairly important CPU due to severity and volume of fixes.
- The remotely exploitable without authentication bug is likely in Application Express (APEX). Any organizations running APEX externally on the Internet should look to apply the relevant patches immediately. To patch APEX, the newest version must be installed, which requires appropriate testing and upgrading of applications.
- There are four cilent-side only installations and likely most are in JDBC.
- Core RDBMS and PL/SQL are listed as patched components, so most likely there are critical security vulnerabilities in all database implementations.
Oracle Fusion Middleware
- There are 17 new Oracle Fusion Middleware vulnerabilities, 13 of which are remotely exploitable without authentication and the highest CVSS score being 7.5.
- Various Fusion Middleware products are listed as vulnerable, so you should carefully review this CPU to determine the exact impact to your environment.
- The core WebLogic Server is listed as a patched component, therefore, most likely all Fusion Middleware customers will have to apply the patch.
Oracle E-Business Suite 11i and R12
- There are nine new Oracle E-Business Suite 11i and R12 vulnerabilities, seven of which are remotely exploitable without authentication. Many of these are in core Oracle EBS components such as Oracle Applications Framework (OAF) and Application Object Library (AOL/FND). Even though the maximum CVSS score is 5.0, most of these vulnerabilities should be considered high risk.
- All DMZ implementations of Oracle EBS should carefully review the CPU to determine if there environment is vulnerable. As all Oracle EBS CPU patches are now cumulative, the CPU patch should be prioritized or mitigating controls, such as AppDefend, be implemented.
- We anticipate this quarter's CPU to be higher risk than most and should be prioritized. Based on the patched components, this may be a higher than average risk CPU for all Oracle database environments.
- As with all previous CPUs, this quarter's security patches should be deemed critical and you should adhere to the established procedures and timing used for previous CPUs.
- For Oracle E-Business Suite customers, DMZ implementations may have to apply this quarter's patch faster than previous quarters due to the number and severity of bugs.
Oracle 12c Real Application Security and Standard Database Auditing - Warning Database Logins Not Logged
Oracle 12c introduces several major new security features. Data redaction is one new feature and Real Application Security (RAS) is another. Per Oracle, RAS is the next generation Virtual Private Database (VPD) and is installed with Oracle Enterprise Edition – no additional license required. RAS is a new declarative and granular authorization model and is designed to be an application security platform for end-to-end application security. For those developing APEX applications (also installed with Enterprise Edition), RAS will certainly become an integral tool.
With RAS, developers define security policies instead of having to create and maintain PL/SQL code. Most notably, RAS however extends the security solution to define both application users and roles separate from database users and roles.
RAS allows for the creation of users, complete with user names and passwords, and stores them in the database. RAS users are not stored in DBA_USERS. RAS users are defined in DBA_XS_USERS, and their passwords are stored in SYS. XS$VERIFIERS.
With 126.96.36.199, RAS users can also directly connect to the database. It appears that with 188.8.131.52, RAS users can be defined with a flag to allow or disallow direct database logons. As any database security monitoring and logging solution should be monitoring database logon activity, it should be known that RAS users will NOT show up in standard Oracle database auditing. Standard database auditing instead picks up login activity by the generic user XS$NULL. Because it is designed to be part of an application, RAS has its own logging and auditing solution.
Basic logon activity for RAS users, however is logged in SYS.UNIFIED_AUDIT_TRAIL. Even if you have NOT enabled Unified Auditing in 12c, SYS.UNIFIED_AUDIT_TRAIL is being populated. Why this is the case will be the topic of another blog post. If you have compliance requirements to log and audit database logons, you will need to monitor SYS.UNIFIED_AUDIT_TRAIL for RAS user activity as well as for the creation of RAS users if not also potentially configuring RAS auditing. The example below should get you started.
With the below you can test for yourself how standard database auditing logs RAS user logons:
- Ensure auditing for create session is enabled, if not: audit create session by access;
- Create Real application security user
- Set password for Real Application Security user
- Review both dba_users and dba_xs_users to see for yourself where RAS users are defined.
- Log into the database with: INTEGRIGY_RAS_USER/oracle
- Look at your auditing and see a logon from XS$NULL instead of INTEGRIGY_RAS_USER
select * from sys.aud$ order by 1 desc
- Now look at SYS.UNIFIED_AUDIT_TRAIL. You will see XS$NULL for the DBUSERNAME but you will see 'INTEGRIGY_RAS_USER' in XS_USER_NAME.
select dbusername,xs_user_name ,event_timestamp
where xs_user_name = 'INTEGRIGY_RAS_USER'
order by event_timestamp
If you are not familiar with XS$NULL, XS$NULL is created when the database component Oracle XML Database (XDB) is installed. XDB is now a mandatory component of 12c and as such, XS$NULL must exist in the database. Per Oracle, XS$NULL is an internal account that represents the absence of a user in a session. It is used by the lightweight session infrastructure for APEX, RAS and XDB and the name of this user is hard coded in those modules. Because XS$NULL is not really a user, this account can only be accessed by the Oracle Database instance. XS$NULL has no privileges, and no one can authenticate as XS$NULL, nor can authentication credentials ever be assigned to XS$NULL.
If you have questions, please contact us at email@example.comReferences
Summary of Real Application Security http://www.oracle.com/technetwork/database/security/real-application-security/real-application-security-1964775.html
Oracle Documentation for Real Application Security http://docs.oracle.com/database/121/DBFSG/intro.htm#DBFSG10000
Is the XS$NULL user a required account? (Doc ID 1556725.1) https://support.oracle.com/rs?type=doc&id=1556725.1
UTL_FILE_DIR is the database initialization parameter the Oracle Database uses to determine what operating system directories and files PL/SQL packages, functions, and procedures may read from or write to when using the standard UTL_FILE database package. The directories specified in the UTL_FILE_DIR parameter may be accessed by any database user, which can be a security issue. In Oracle 9iR2, Oracle released new functionality called “Directories” that provides a more secure and robust capability to access operating system directories and files. The advantages of using Directories over UTL_FILE_DIR are –
- Read and/or Write access to a Directory can be granted to individual database accounts or roles
- A Directory can be added without having to bounce the database
- Directory name is used in the UTL_FILE.FOPEN statement rather than the directory path, which allows changes to the directory path without modification to the PL/SQL source code
The UTL_FILE database package is used to read from and write to operating system directories and files. By default, PUBLIC is granted execute permission on UTL_FILE. Therefore, any database account may read from and write to files in the directories specified in the UTL_FILE_DIR database initialization parameter.
Oracle usually assumes that PUBLIC has execute permission on UTL_FILE, therefore, many Oracle product installations do not specifically grant execute permission on UTL_FILE to Oracle installed database accounts. Consequently, revoking execute permission on UTL_FILE from PUBLIC will result in errors in a number of standard Oracle database utilities and The Oracle E-Business Suite. Also, some Oracle products and third party products will grant execute on UTL_FILE to PUBLIC during the installation of the product.
We do not recommend revoking execute permission on UTL_FILE from PUBLIC in database instances running the Oracle E-Business Suite and other complex applications (i.e., SAP, Peoplesoft, Oracle Clinical, etc.) due to the possibility of encountering errors in the application and third party products. Only revoke execute permission from PUBLIC in database instances where the application, third party products, and all database management tools can be thoroughly tested. All Oracle delivered products must be tested since Oracle often assumes UTL_FILE is granted to PUBLIC and does not provide the necessary grants when any products are installed – this includes products like Enterprise Manager Grid Control and Apex.
Security considerations with UTL_FILE can be mitigated by removing all directories from UTL_FILE_DIR and using the Directory functionality instead.Oracle E-Business Suite and UTL_FILE_DIR
The combination of UTL_FILE being granted to PUBLIC and UTL_FILE_DIR being publicly accessible creates a significant security issue for the Oracle E-Business Suite. The Oracle E-Business Suite uses UTL_FILE_DIR to read and write concurrent manager request temporary files. Also, UTL_FILE_DIR is extensively used by most organizations to access interface and conversion data files from PL/SQL interface programs.
In the Oracle E-Business Suite, UTL_FILE_DIR is usually set to include at least the directories specified in $APPLPTMP and $APPLTMP – in the default installation this will include at least “/usr/tmp”. Frequently, additional custom directories will be included for custom interfaces and other custom programs.
By accessing the APPLSYSPUB database account, an attacker can easy read and write interface data files. Depending on the exact configuration, implemented modules, and custom interfaces, this could allow access to sensitive information including social security numbers and credit card numbers.Migrating From UTL_FILE_DIR
For Oracle E-Business Suite customers, migrating from UTL_FILE_DIR to Directories requires only minimal changes and may require no source code changes depending on the design of the interfaces and other custom programs. The steps are as follows -
- Identify where UTIL_FILE is used
- Create Directories
- Change FOPEN calls to use Directories
- Edit UTL_FILE_DIR to remove physical Directories
Step One – Identify Where UTIL_FILE Is Used
The most difficult issue is identifying the packages, functions, and procedures using the physical directories in UTL_FILE_DIR. The UTL_FILE_DIR physical directories are only directly referenced by the UTL_FILE.FOPEN function. The FOPEN specifies the operating system directory and file name to open. All subsequent read, write, and close function calls use the file handle returned by FOPEN.
The following SQL may assist in identifying uses of UTL_FILE_DIR in FOPEN statements –
SELECT * FROM dba_source WHERE upper(text) like '%FOPEN%' AND name like '%<custom prefix>%' AND owner = 'APPS'
If the calls to FOPEN are not in a common function and are not accessed through some other indirection, it should be fairly straightforward to find and change the necessary FOPEN references in any custom PL/SQL packages, functions, and procedures. If the physical directory paths are stored in a table or in a concurrent program definition, then no changes to the source code are required.
At this time, converting the standard the Oracle E-Business Suite directories ($APPLPTMP and $APPLTMP) is not recommended as this is not supported by Oracle. Theoretically it should work without any issues, however, the Oracle E-Business Suite references the directories in multiple places including the $APPLPTMP and $APPLTMP environmental variables, system profile options (e.g., “ECX: XSLT File Path”), and potentially in some configuration files.
Step Two – Create Directories
The following general steps are required to change the references from UTL_FILE_DIR to Directories. Please note that the directory name MUST always be in uppercase in all UTL_FILE.FOPEN statements, otherwise errors may be encountered
For each custom directory in UTL_FILE_DIR, execute the following SQL statements in each development, test, and production database instance –
CREATE OR REPLACE DIRECTORY <name> AS '<physical directory path>';
GRANT READ, WRITE ON DIRECTORY <name> TO APPS;
as an example –
CREATE OR REPLACE DIRECTORY TMP_DIR AS '/usr/tmp';
GRANT READ, WRITE ON DIRECTORY TMP_DIR TO APPS;
The directories “/usr/tmp” and “../comn/temp” and any other directories specified in $APPLPTMP and $APPLTMP should remain in UTL_FILE_DIR, since these directories are required by Oracle.
Step Three – Change FOPEN Calls to Use Directories
Once directories have been created the next step is to edit your code to use them. The process is straightforward. If a physical directory is specified in the UTL_FILE.FOPEN statement, change the hard-coded path to the Directory name.
As an example –
FILE_ID := UTL_FILE.FOPEN('/usr/tmp', 'dummy.txt', 'W');
change to –
FILE_ID := UTL_FILE.FOPEN('TMP_DIR', 'dummy.txt', 'W');
Two pointers to keep in mind:
- Always be sure to use the directory name in uppercase and it must be enclosed in single quotes
- If the physical directory is specified in a table or as a parameter in a Concurrent Program definition, then just specify the Directory name rather than a physical path – /usr/tmp becomes TMP_DIR
Step Four – Edit UTL_FILE_DIR to Remove Physical Directories
Remove all the custom physical directories from UTL_FILE_DIR. The standard Oracle directories of ‘/usr/tmp’, ‘../comn/temp’, etc. should not be removed. The database must be bounced for the change to take effect.
If you have questions, please contact us at firstname.lastname@example.orgReferences
- Using CREATE DIRECTORY Instead of UTL_FILE_DIR init.ora Parameter”, Oracle Metalink, Metalink Note ID 196939.1 https://support.oracle.com/rs?type=doc&id=196939.1