A new class of vulnerability?

A few days ago David Litchfield published a detailed analysis of the Oracle vulnerability he has found in February this year. The title says: "Lateral SQL Injection: A New Class of Vulnerability in Oracle". Finding the bug was a nice catch, but actually the feature leading to it is a pretty trivial source of problems, namely automatic datatype conversions.

I think every serious programming language should not have automatic type conversions. It makes life a hell lot easier for developers (you can write the same code with a lot less chars), but you're guaranteed that you'll hit your head in the wall at least a couple of times when you realize that type conversion (that you were not aware of at the moment of coding) was responsible for some odd behaviour. And as David proved, automatic type conversion can be a built-in bomb just waiting to be exploited.

Let's take a look at David's exploit. He used the session variable NLS_DATE_FORMAT to inject arbitrary code execution into some precompiled (and supposingly privileged) PL/SQL code. In all his examples he takes advantage of the PL/SQL level automatic datatype conversion that occurs when you assign a DATE variable's value to a string type variable. In his example the date_proc function concatenated a DATE variable to a literal string which triggered an implicit and automatic DATE->VARCHAR2 type conversion and thus used the NLS_DATE_FORMAT parameter while doing so. In his other example he used a statement like SELECT SYSDATE FROM DUAL, but the client (probably SQLPlus) did an automatic conversion again.

What I'm trying to say is that the flaw David found is actually not a design flaw, it's bad coding practice. Using the SQL engine of the Oracle RDBMS does not imply any extra risks due to this vulnerability. The automatic datatype conversion of PL/SQL is a convenience feature, but if programmers are not aware of its presence (which might happen even to experienced programmers from time to time), then it can impose a serious security risk. That's why I prefer languages with strict type checking.

The vulnerability found by David can be easily nullified by using bind variables ... which should be the case anyway. Write down this on your palm with a permanent ink so you won't forget: never use concatentation to add a variable to an SQL statement, always use bind variables.