Oracle Database Function Buffer Overflows and SQL Injection Attacks

Integrigy Security Note

______________________________________________________________________

 

Using Database Functions in SQL Injection Attacks

May 1, 2003

______________________________________________________________________

 

Summary:

 

Many web applications are vulnerable to SQL injection attacks that make use of database functions.  Any dynamic SQL statement that uses un-validated end-user string input can be exploited by this type of SQL injection attack.

 

This specific type of SQL injection is not new, however it is not well understood by many application developers.  Our audits of web applications reveal many are vulnerable to database function injection attacks, but most are well protected against other variations of SQL injection attacks.

 

We believe next generation automated attack tools and even possibly worms will leverage function-based SQL injection attacks because a single injection string can be used repeatedly against every input field of a web application in order to locate vulnerabilities.  Since the databases for many web applications are located behind firewalls, these automated attacks can be used to launch attacks on internal networks.

_______________________________________________________________________

 

Background:

 

Most documented SQL injection attacks rely on injecting code into specific SQL statements that execute critical application logic such as authentication.  By manipulating certain dynamic SQL statements, an attacker can gain escalated privileges or view arbitrary data in the database.  A typical attack attempts to add code like “or ''=''” to an authentication query or add a UNION to a query that retrieves rows to be displayed.

 

For databases that support multiple SQL statements in a single request (Microsoft SQL Server and PostgreSQL), dynamic SQL statements can be exploited simply by adding a second statement.  An attacker can inject INSERT statements to add new users to the application or any other SQL statement (e.g., DROP TABLE).

 

Oracle and IBM DB2 databases have fared better against SQL injection attacks since there is no multiple SQL statement support, no EXECUTE statement (SQL Server), and no INTO OUTFILE function (MySQL).

 

 

Description:

 

Integrigy has performed detailed security audits of many commercial, open-source, and custom developed applications that use Oracle as the back-end database.  We discovered that more than 80% of these applications were vulnerable to SQL injection attacks that exploit database functions; most were not vulnerable to other types of SQL injection attacks.

 

Standard SQL permits functions to be executed as part of any SQL statement.  Functions can be embedded in the columns portion or the where clause of any SELECT, INSERT, UPDATE or DELETE statement and can be standard database functions or user defined functions.  Functions used in a SELECT statement can not perform database write operations, except in special circumstances.  For most databases, functions in INSERT, UPDATE, and DELETE statements can write to the database.   

 

We believe Oracle and IBM DB2 databases are most vulnerable to function-based SQL injection attacks because of the large number of standard functions available, extensive use of database stored procedures in applications, and lack of awareness of this injection possibility by many application developers.

 

By default, the Oracle database has over 1,000 available functions in about 175 standard database packages.  Only a few of these functions may be useful in SQL injection attacks, however some of these standard functions do perform network activities which can be exploited.  Also, Oracle allows any custom function or function residing in a custom package to be executed in a SQL statement.

 

Many application developers believe only certain dynamic SQL statements are vulnerable to SQL injection and tend to protect just a few critical SQL statements.  With function-based injection attacks, every dynamic SQL statement that uses un-validated passed string input is vulnerable.  The fundamental issue seems to be that to protect every dynamic SQL statement requires additional coding effort by the developer (for Java usually 2 to 4 lines per SQL statement).

 

SQL Server is not as vulnerable to function-based SQL injection attacks as other databases since the most useful functions for a successful attack are actually extended stored procedures, not functions.  Extended stored procedures are run using the EXECUTE statement and can be easily injected because SQL Server supports multiple SQL statements per database request.  Exploits of extended stored procedures are numerous, well known, and well documented -- most application developers using SQL Server realize the potential risk.  If a web application using SQL Server as the database is vulnerable to SQL injection, using an EXECUTE statement will be a more effective attack than exploiting the standard SQL Server functions. 

 

 

Risk:

 

We consider the risk of function-based SQL injection attacks greater than for other types of SQL injection attacks since a function-based attack can be automated and can potentially exploit many more dynamic SQL statements in an application.  The same exploit string should work for many SQL statements and a few simple variations of the exploit string should work for almost all vulnerable SQL statements.  Other types of SQL injection attacks require a carefully crafted exploit string intended for the specific SQL statement.

 

Restricting access to standard and custom database functions mitigates much of the risk of a function-based SQL injection attack.  The availability of these standard functions (e.g., UTL_HTTP in Oracle) poses the greatest and access should be restricted whenever possible.

 

The risk of function-based SQL injection attacks is aggravated by the number of buffer overflows discovered in the standard functions of many databases.  The following is a list of the standard database functions that have known buffer overflows (patches are available for all these vulnerabilities) -

 

  Oracle – tz_offset, to_timestamp_tz, bfilename

PostgreSQL – cash_words, circle_poly, path_add, path_encode, repeat

SQL Server – pwdencrypt, raiseerror, formatmessage, openrowset

 

All of these buffer overflows can be exploited via SQL injection attacks.  The effectiveness of such an attack depends on the function, operating system, and database, nevertheless at least a denial of service attack will most likely be the result for an un-patched database.

 

 

Solution:

 

The standard defenses for SQL injection attacks will also stop all function-based injection attacks.  The following steps will prevent all SQL injection attacks –

 

1.        Validate all string input and escape all single quotes

2.        Use bind variables instead of dynamically generated SQL

3.        Restrict access to standard database functions and procedures

4.        Restrict access to custom database stored procedures

 

The exact implementation of the above defenses will depend on the programming language and database.  For more information on protecting web applications running on Oracle from SQL injection attacks, see our whitepaper “Rethinking SQL Injection Attacks against Oracle Databases” at http://www.integrigy.com/resources.htm.

 

For most databases, the default installation provides unrestricted access to many standard stored procedures and functions.  Most of these are not required by a web application and access should be restricted.

 

As a long term solution, code reviews and audits should be performed of web applications.  Coding standards should require user input validation and use of bind variables for all dynamic SQL statements that are created with end-user input.  Every dynamic SQL statement that utilizes passed string input must be reviewed.

 

For additional information regarding function-based SQL injection attacks, please contact us at alerts@integrigy.com.

 

 

References and Additional Information:

 

   “Rethinking SQL Injection Attacks against Oracle Databases”

http://www.integrigy.com/resources.htm

 

“OWASP – A Guide to Building Secure Web Applications”

http://umn.dl.sourceforge.net/sourceforge/owasp/OWASPGuideV1.1.1.pdf

 

“Introduction to Database and Application Worms”

http://www.appsecinc.com/presentations/DB_APP_WORMS.pdf

 

Additional Information on SQL Injection Attacks –

http://www.securityfocus.com/infocus/1644

http://www.nextgenss.com/papers/advanced_sql_injection.pdf

http://www.spidynamics.com/whitepapers/WhitepaperSQLInjection.pdf

 

Oracle Database Security Checklist –

http://otn.oracle.com/deploy/security/oracle9i/pdf/9ir2_checklist.pdf

 

Oracle Function Buffer Overflows –

http://technet.oracle.com/deploy/security/pdf/2003alert48.pdf

http://technet.oracle.com/deploy/security/pdf/2003alert49.pdf

http://technet.oracle.com/deploy/security/pdf/2003alert50.pdf

http://www.nextgenss.com/advisories/ora-tzofstbo.txt

http://www.nextgenss.com/advisories/ora-bfilebo.txt

http://www.nextgenss.com/advisories/ora-tmstmpbo.txt

 

PostgreSQL Function Buffer Overflows -

http://www.securityfocus.com/bid/6615

http://www.securityfocus.com/bid/6614

http://www.securityfocus.com/bid/6610

http://www.securityfocus.com/bid/5527

http://www.securityfocus.com/bid/5497

 

SQL Server Database Security Checklist –

http://www.sqlsecurity.com/checklist.asp

 

    SQL Server Function Buffer Overflows –

http://www.microsoft.com/technet/security/bulletin/MS02-040.asp

http://www.microsoft.com/technet/security/bulletin/MS01-060.asp

http://www.securityfocus.com/archive/1/276953

http://www.nextgenss.com/advisories/mssql-ors.txt

http://www.atstake.com/research/advisories/2001/a122001-1.txt

 

 

______________________________________________________________________

 

About Integrigy Corporation (www.integrigy.com)

 

Integrigy Corporation is a leader in application security for large enterprise, mission critical applications. Our application vulnerability assessment tool, AppSentry, assists companies in securing their largest and most important applications. Integrigy Consulting offers security assessment services for leading ERP and CRM applications.

 

For more information, visit www.integrigy.com.