Risk Associated with Cursor Snarfing

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.

 Share this post