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