Pete Finnigan's Oracle Security Weblog

I covered the pre-release announcement for the July 2008 Critical Patch Update (CPU) here a few days ago in a post titled "Oracle Patch Tuesday Is Coming". Nothing new and major this time from the perspective of the pre-release report. I was intrigued when I looked at google news today and saw very few news reports so far on the latest in the long line of CPU releases. The pre-release note posted a week ago attracted at least 45 news reports according to Google but the actual release had 4 when i looked this morning (I guess its increased by now).

This is interesting, is it because these patches (in the scale of Oracle security things) is getting less significant, or maybe people are not as excited as they have been in the past as there are no directly exploitable database flaws this time without authentication? - who knows.

Oracle's advisory is released as a page titled Oracle Critical Patch Update Advisory - July 2008. The things of interest are that there are a few new names credited on the advisory that are not usually there and also that Laszlo has been post-credited for a fix delivered in the January CPU. The types of fixes / bugs are similar to those reported and fixed in previous CPU's.

The interesting point is that David Litchfield has yesterday released an advisory for a bug he reported on 9th Oct 2007 where the application server can be expolited remotely by an un-authenticated attacker that allows full control to be gained of the backend database server remotely from a webserver. The details posted by David to various lists are repeated here as a quote:

"Oracle Application Server installs a number of PLSQL packages in the backend
database server. One of these is the WWV_RENDER_REPORT package and it is
vulnerable to PLSQL injection. This package uses definer rights execution
and therefore executes with the privileges of the owner, in this case the
highly privileged PORTAL user.


Specifically, the SHOW procedure takes as its 2nd argument the name of a
function to execute and this is embedded with a dynamically executed
anonymous block of PLSQL without first being sanitized. Because it is a
block of anonymous PLSQL, an attacker can exploit this flaw to run any SQL
statement, for example, create new users, grant dba privileges, delete or
modify data. This is achieved by wrapping the statement(s) within an
"execute immediate" statement and specifiying the autonomous_transaction
pragma."

This is potentially dangerous for anyone who understands this can easily exploit it based on the information delivered to the full-disclosure list and especially if the CPU is not applied.