Philosophy

Oracle extproc Overflow

Oracle issued Security Alert 57 regarding the extproc overflow ”the alert can be found at http://otn.oracle.com/deploy/security/pdf/2003alert57.pdf . The Next Generation Software (NGS) advisory can be found at www.nextgenss.com/advisories/ora-extproc.txt .

In September 2002, Next Generation Software performed a rigorous investigation of the Oracle RDBMS to look for security flaws, because the authors felt that the Oracle DBMS had been under- audited by the rest of the security community. David Litchfield had previously found a bug in the extproc mechanism, so we decided to take another look in that general area. It's important to understand the architectural details here that relate to how this first bug was discovered .

In general, advanced DBMSs support some dialect of Structured Query Language (SQL) that allows for more complex scripts and even procedures to be created. In SQL Server, this is called Transact-SQL , and allows things like WHILE loops , IF statements and so on. SQL Server also allows direct interaction with the operating system via what Microsoft terms "extended stored procedures" ”these are custom functions implemented in DLLs that can be written in C/C++.

Historically, there have been many buffer overflows in SQL Server's extended stored procedures, so it's logical to believe that analogous mechanisms in other DBMSs will suffer from similar problems. Enter Oracle.

Oracle offers a mechanism that is much richer than SQL Server's extended stored procedure mechanism in that it allows you to call arbitrary library functions, not just functions conforming to some predefined specification. In Oracle, calls out to external libraries are called external procedures , and are carried out in a secondary process, extproc . extproc is offered as an additional Oracle service, and can be connected to in a similar manner to the database service itself.

Another important thing to understand is the Transparent Network Substrate protocol (TNS). This is the part of the architecture that manages the Oracle process's communication with clients and with other parts of the system. TNS is a text-based protocol with a binary header. It supports a large number of different commands, but the general purpose is to start, stop, and otherwise manage Oracle services.

We looked at this extproc mechanism, and decided to instrument it to see what it did. We were running Oracle on the Windows platform, so we took all the standard sockets calls in the Oracle process and breakpointed them ” connect , accept , recv , recvfrom , readfile , writefile , and so on. We then made a number of calls to external procedures.

David Litchfield discovered that when Oracle called out to an extended stored procedure, it used a series of TNS calls followed by a simple protocol to make the call. There was absolutely no authentication; extproc simply assumed that it must be Oracle talking on the other end of the connection. The implication of this is that if you can (as a remote attacker) direct extproc to call the library of your choice, you can easily compromise the server, by (say) running the system function in libc or msvcrt .dll on Windows. There are a number of mitigating factors, but in a default installation (before Oracle fixed this bug), this was the case.

We reported this to Oracle and worked with them to put out a patch. You can find the Oracle alert (number 29) at http://otn.oracle.com/deploy/security/pdf/plsextproc_alert.pdf . David Litchfield's advisory is available at www.nextgenss.com/advisories/oraplsextproc.txt .

Because this area of Oracle's behavior is so sensitive (in terms of the security of the system), we decided to again review all the behaviors that relate to external procedures to see whether we could find anything more.

The way you make the aforementioned call is fairly simple ”you can see the TNS commands by debugging Oracle and running the following script (from David's excellent "HackProofing Oracle Application Server" paper, which can be found at www.nextgenss.com/papers/hpoas.pdf ).

 Rem Rem oracmd.sql  Rem  Rem Run system commands via Oracle database servers  Rem  Rem Bugs to david@ngssoftware.com  Rem      CREATE OR REPLACE LIBRARY exec_shell AS  'C:\winnt\system32\msvcrt.dll';  /  show errors  CREATE OR REPLACE PACKAGE oracmd IS  PROCEDURE exec (cmdstring IN CHAR);  end oracmd;  /  show errors  CREATE OR REPLACE PACKAGE BODY oracmd IS  PROCEDURE exec(cmdstring IN CHAR)  IS EXTERNAL  NAME "system"  LIBRARY exec_shell  LANGUAGE C; end oracmd; / show errors 

Then you run the procedure

 exec oracmd.exec ('dir > c:\oracle.txt); 

to kick off the actual execution.

Starting at the beginning, we tried the usual things in the create or replace library statement by manually plugging in queries and seeing what happened (in the debugger and in FileMon ). Surprisingly, when we submitted an overly long library name:

 CREATE OR REPLACE LIBRARY ext_lib IS 'AAAAAAAAAAAAAAAAAAAAAAAAA...'; 

and then called a function in it:

 CREATE or replace FUNCTION get_valzz    RETURN varchar AS LANGUAGE C      NAME "c_get_val"  LIBRARY ext_lib;     select get_valzz from dual; 

something weird happened, not to Oracle itself, but apparently somewhere else ”the connection was being reset ”which would normally indicate some sort of exception. The odd thing was that it didn't occur in the Oracle process.

After looking at FileMon for a while, we decided to debug the TNS Listener ( tnslsnr ) process (which handles the TNS protocol and is the intermediary between Oracle and extproc when calling external procedures). Since the tnslsnr process starts extproc , we used WinDbg, which allows for easy tracing of child processes. The process was a little involved.

 1) Stop all oracle services 2) Start the oracle database service ('OracleService<hostname>') 3) From a command line session in the interactive desktop, start windbg  -o tnslsnr.exe 

This causes WinDbg to debug the TNS Listener and any processes that the TNS Listener starts. The TNS Listener is running in the interactive desktop.

Sure enough, once we did this, we saw the magic exception in WinDbg .

 First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000001 ebx=00ec0480 ecx=00010101 edx=ffffffff esi=00ebbfec edi=00ec04f8 eip=41414141 esp=0012ea74 ebp=41414141 iopl=0         nv up ei pl zr na po nc cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010246 41414141 ??               ??? 

This was indicative of a vanilla stack overflow in extproc.exe . A quick set of tests revealed that the problem didn't affect only the Windows platform.

We have one vector to trigger the bug ”via the create library statement. But, harking back to David's original extproc advisory, we recalled that it's possible to make calls to extproc directly as a remote attacker. We then coded up a quick harness to remotely trigger the overflow and discovered that it works the same way. We had found a remote unauthenticated stack overflow in Oracle. So much for " Uunbreakable "!

Apparently, this vulnerability was introduced in the patch to the previous bug ”the functionality introduced to log the request to run the external procedure is vulnerable to an overflow.

To summarize the process behind the discovery of these two bugs:

  • We were aware of a probable architectural weakness, in that we knew that SQL Server had problems in this general area of functionality. We therefore considered it likely that Oracle would suffer from a similar problem, since accessing stored procedures a difficult thing to do safely.

  • Carefully instrumenting and tracing the behavior of Oracle led us to the possibility of executing external procedures without authentication ”bug number one.

  • Revisiting this area of functionality, we found that something strange happened with overly long library names (since the patch to the first extproc bug).

  • We instrumented with debuggers and a file-monitoring tool (Russinovich and Cogswell's excellent FileMon ) and identified the components in question.

  • Upon debugging the components in question, we saw the exception indicating the stack overflow ”bug number two.

At no point did we automate anything; it was all based on looking carefully at the construction of the system under test and disregarding the documentation, preferring instead to understand the system in terms of its instrumented behavior.

As a footnote to this exercise, Oracle has now included an excellent set of workaround information for these bugs in Alert 57 as well as a patch that fully addresses both issues.



The Shellcoder's Handbook. Discovering and Exploiting Security
Hacking Ubuntu: Serious Hacks Mods and Customizations (ExtremeTech)
ISBN: N/A
EAN: 2147483647
Year: 2003
Pages: 198
Authors: Neal Krawetz

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net