Look before you leap...
So after publishing my paper the other day I've received a number of mails and comments from people who clearly don't quite "get it". Let me correct some of the more common comments and misconceptions.
1) You have to be highly privileged to do this.
No, you don't - in a multistage attack you can get what you need. To effect an attack, as described in the paper, you need to acquire the ALTER SESSION privilege. You can get this by exploiting another flaw such as DB04 in the April 2008 Critical Patch Update. This is a injection flaw into a ALTER SESSION statement. Furthermore, prior to Oracle 10gR2 the CONNECT role had the ALTER SESSION privilege.
2) You need direct access to the database to effect this attack
No, you don't. The attack described in the paper can be launched via the web through Oracle Application Server for example. Again, it's a multistage attack, but easily doable. Just use any one of the 5 bypass techniques I've published over the past few years and if the app server is patched against all those then look for an initial inject point in the custome app and use any of the facilitator methods I've described in the past.
3) This is simply second order SQL injection.
No, it's not, but it is similar. Second order SQL injection is where you load up a table with your attack SQL. At some later point this SQL is selected as data from the table and embedded in a dynamic query. The attack described in my paper doesn't deal with stored data. It manipulates the way the date and time is treated.
4) This paper is pointless as you should be using bind variables for dynamic queries, anyway.
Many developers only use bind variables when dealing with varchar data and input as they are known to be dangerous. They won't use bind variables when it comes to DATE or NUMBER data types. The whole point of the paper is to prove that DATA and NUMBER data types can be dangerous and that bind variables should be used.
5) This paper is mostly academic
No, it's not. This presents a potential threat to PL/SQL applications. Developers should take heed. Suggesting otherwise is irresponsible.
David on 04.29.08 @ 12:22 AM GMT [link]
