- 11g (12)
- Allgemein (29)
- David Litchfield (7)
- Exploit (23)
- Forensics (7)
- Oracle Security (105)
- passwords (8)
- Repscan (1)
- Security (22)
- Sentrigo (5)
- software (9)
- source code audit (5)
- SQL Injection (24)
- Tools (24)
- Trainings (3)
- Tutorial (2)
- 18 Nov 2011: DOAG 2011 Presentation "Best of Oracle Security 2011"
- 15 Okt 2011: Oracle Critical Patch Update Pre-Release Announcement - October 2011
- 17 Sep 2011: Disable Auditing and running OS commands using oradebug
- 13 Apr 2011: Blackhat Training "HACKING AND SECURING ORACLE (2 days) "
- 2 Apr 2011: Oracle Database 11.2 Express Edition Beta comes with weak default password
- 23 Mrz 2011: McAfee acquires Sentrigo
- 12 Okt 2010: TDE decrypt utilities and TDE/Password flash demo
- 22 Sep 2010: Marcell published "Writing your own password cracker" presentation
- 21 Sep 2010: Laszlo's presentation "Oracle Post Exploitation Techniques" and Marcel's Sybase ASE Password Cracker
- 10 Sep 2010: Update of "Project Lockdown" released
Oracle Security
SQL Injection
- November 2011
- Oktober 2011
- September 2011
- April 2011
- März 2011
- Oktober 2010
- September 2010
- August 2010
- April 2010
- März 2010
- Februar 2010
- Januar 2010
- Dezember 2009
- November 2009
- Oktober 2009
- September 2009
- August 2009
- Juli 2009
- Mai 2009
- April 2009
- März 2009
- Februar 2009
- Januar 2009
- Dezember 2008
- November 2008
- Oktober 2008
- August 2008
- Juli 2008
- Mai 2008
- April 2008
- März 2008
- Februar 2008
- Januar 2008
- Dezember 2007
- November 2007
- Oktober 2007
- September 2007
- August 2007
- Juli 2007
- Juni 2007
- Mai 2007
Oracle, white spaces and unexpected behaviour
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.
3 Antworten auf “Oracle, white spaces and unexpected behaviour”
Antwort schreiben
Sie müssen als angemeldet sein, um einen Kommentar schreiben zu können.
15 Jan 2008 bei 13:25
mysql> select/**/current_user;
+—————-+
| current_user |
+—————-+
| root@localhost |
+—————-+
1 row in set (0.00 sec)
Best regards
Maxim
15 Jan 2008 bei 21:25
From SQl Server 2005 SQLCMD
1> select/*a*/count(*)/*b*/from/*c*/information_schema.tables
2> go
———–
559
(1 rows affected)
1> select top 3 1.x from information_schema.tables
2> go
x
—
1
1
1
(3 rows affected)
1>
15 Jan 2008 bei 21:27
Maxim and Gary,
thank you for the update.
Regards
Alex