The first exploits for CPU January 2008 were published on milw0rm.com.
Alexandr Polyakov from Digital Security published 4 exploits for XMLDB. Alexandr found and reported these vulnerabilities mid of december 2007 to Oracle. It seems that someone else reported these errors before because Oracle NEVER fixes vulnerabilities within less than a month.
Oracle just released their latest Oracle Critical Patch Update (CPU) January 2008. As promised in the prelease announcement the patch contains 8 fixes for the database itself. As usual most of the vulnerabilities are coming from the usual suspects (Esteban, Joxean, David, Alex) and some other people like Pete Finnigan, Mariano Nunez Di Croce, Ali Kumcu and Alexandr Polyakov.
According to an email from Oracle secalert they fixed 7 of my vulnerabilities (tracking numbers: 6980733, 7520291, 9675443, 9675563, 9675681, 9675695, 9675857) but they mapped them to DB05, DB04 and DB02.
The highest database CVSS rating of 6.5 has DB01.
DB02, DB03, DB04 and DB05 are SQL Injection vulnerabilities allowing privilege escalation.
The highest application server CVSS ratings of 9.3 are 2 bugs (AS01, AS02) in Oracle Jinitiator 1.1.8.26 and 1.3.1.27 and affects clients only.
Other interesting information are described in the Metalink note 466757.1. With this CPU it is necessary to recompile ALL Views to fix the „VIEW“ problems fixed with Oracle CPU July/October 2007.
Last week I saw the blog entry „select 1.x from t1“ from Laurent concerning white spaces in select statements and Tom Kyte’s answer with a short explanation. Tanel Poder wrote a blog entry „Can you write a working SQL statement without using any whitespace?“ too.
In my opinion and from the security perspective making whitespaces optional in SQL statements is a bad idea because it’s an unexpected behavior. And this is always a bad idea.
Here a real life example from Oracle itself:
Two years ago I found a SQL Injection Vulnerability in the web component of XMLDB.
The exploit was looking like:
http://url/xmldb?param1=’||(select sysdate from dual)||‘
The result was a HTTP page containing the current date in an Oracle error message, a common exploit technique used by attackers.
The bugfix from the Oracle developer responsible for this component was to filter the URL for white spaces. Whenever a whitespace was part of the URL, the query was rejected. That’s why it was still possible to use functions (e.g. SYS_CONTEXT, …) but select statements were refused.
At that time I was not aware that SQL statements can be constructed without white spaces.
But with the knowledge from Laurent’s and Tanel’s blog entries I could rewrite the exploit
http://url/xmldb?param1=’||(select/**/sysdate/**/from“DUAL“)||‘
A quick check in the Oracle PL/SQL code shows that some Oracle packages are using whitespaces as token separator (with the function instr()). I was also able to create a buffer overflow with alter session (11g) in SQL*Plus using this technique. I will digg deeper…
Quick question to my readers: Is this just an Oracle behavior or also possible in other databases like SQLServer or DB2.
Today Sentrigo published a press release saying that in a survey 67% of the attendees never apply Oracle Critical Patch Updates on their system.