Oracle Security Alert Analysis

Sunday, August 19, 2012

Alexander Rothacker


Here’s an update on the Oracle vulnerability we discussed recently. Oracle issued a Security Alert to address the vulnerability.

For those of you who didn’t read the post last week, read the overview section below to get up to speed. Everyone else can skip down to the Who Is Vulnerable section.

At the 2012 Black Hat Conference in Las Vegas, David Litchfield released the details of yet another unpatched Oracle vulnerability.  Litchfield’s presentation was an examination of Oracle index security and provided explanations and demonstrations of various index security issues fixed in recent critical patch updates. 

Included were CVE-2010-0902, CVE-2011-3512 and CVE-2012-0552. He also exposed a new 0-day vulnerability and provided a full demo. This vulnerability is now tracked as CVE-2012-3132 and a patch and workaround has been made available by Oracle.


So, what is this new vulnerability all about? It’s a privilege escalation vulnerability that gives an attacker SYSDBA privileges. In order to perform the exploit, one needs to have CREATE TABLE and CREATE PROCEDURE privileges as well as EXECUTE privileges on DBMS_STATS package.

Also, Oracle Text needs to be available. In a properly configured system, most users should not have above privileges, but application developers and some others typically do have these privileges.   In addition, many common software packages don’t implement proper separation of duties and grant the app account excessive privileges which can be used to exploit this vulnerability.

Who is vulnerable?

On August 10th, Oracle has released a Security Alert with patches available for 10gR2 and later. There is no patch available for older systems. Our testing has also revealed that the July 2012 CPU includes fixes for Oracle 11gR2 ( and, but not for other releases of Oracle. The DBMS_STATS package has been around since Oracle 8i, Oracle Text since Oracle 9i. We believe that all versions of Oracle Database from 9i to 11gR2 are vulnerable if not patched.

How to protect a system

The best way to protect a system from this vulnerability is to apply the patches released in Oracles Security Alert. These patches are comprehensive and protect not just from this one attack, but cover a whole class of attacks.What can be done if a system can’t be patched immediately, or is an older unsupported version?

In the Security Alert, Oracle provides guidance on how to create a trigger that will prevent any exploit attempt using a SQLInjection vulnerability exploited by using single quotes in object names. TeamSHATTER recommends implementing this trigger even on patched systems, since it is more generic and might prevent exploitation by similar attacks.

Other actions would be to check if Oracle Text and DBMS_STATS are installed on the system. If one of them is not, then the system is not vulnerable. By default, both these packages are installed.

Then assess which users on the system have the permissions necessary to exploit the vulnerability. To do this, you must identify all users that have CREATE TABLE, CREATE PROCEDURE and EXECUTE privileges on DBMS_STATS and CTXSYS.CTX_DDL. A good user rights management system will identify these users.

Once the users are identified, remove these privileges from any user that does not require them. For all users that do require these privileges, make sure to audit and/or monitor all calls to CREATE INDEX with an INDEXTYPE of CTXSYS.CONTEXT and calls to DBMS_STATS.GATHER_TABLE_STATS. Any indexes for columns that include single quotes  ‘‘ in the column name are a red flag, and indicate a possible attack.

Cross-posted from TeamShatter

Possibly Related Articles:
Information Security
SQl Injection Patching Databases Oracle Vulnerabilities Exploits Privilege Escalation Analysis
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.