Lateral SQL injection paper

[pmeunier at cerias.purdue.edu (Pascal Meunier)]

If I understand this correctly, it's difficult to exploit because if you can alter database types, you probably can 
send arbitrary SQL statements to the database somehow already.  In that case, what extra capabilities does this attack 
give you?  

When I design applications using Postgresql, I define a "client" role that can only execute stored procedures (and 
nothing else) that were defined by another "definer" role with limited privileges (e.g., not create or drop tables, and 
certainly not redefine types...), and those procedures are executed with the privileges of the definer ("EXTERNAL 
SECURITY DEFINER;").  So, the client is quite constrained in its capabilities.  Wouldn't the application of this scheme 
to an Oracle back-end prevent this attack?  If so then it's not just a question of input validation, but of proper and 
careful configuration of database roles.  

Isn't this something that Oracle could "fix" relatively easily?  For example, by forbidding the redefinition of 
fundamental database types by default in new roles?  This would be an application of the principle of secure defaults.  
That functionality could even be phased out eventually, as I can't imagine that it's needed much if at all.  Usually 
when one claims a "class of vulnerabilities", this is something that can't be fixed in a language or technology, and 
that becomes the responsibility of developers.  I find it strange to claim a "new class of vulnerability" when it's 
something peculiar to Oracle that can likely be fixed by Oracle itself so it's more like an Oracle bug.  This sounds 
perhaps worthy of a CVE entry (a vulnerability in Oracle) but not a CWE entry (a class of vulnerabilities).  I agree 
that doing validation at multiple layers can be beneficial, and that it is required when trust boundaries are crossed, 
but the importance of the find seems a little exaggerat
ed.

Regards,
Pascal Meunier


Kenneth Van Wyk wrote:
> Greetings SC-Lers,
>
> Things have been pretty quiet here on the SC-L list...
>
> I hope everyone saw David Litchfield's recent announcement of a new
> category of SQL attacks.  (Full paper available at
> http://www.databasesecurity.com/dbsec/lateral-sql-injection.pdf)
>
> He refers to this new category as "lateral SQL injection" attacks.  It's
> very different than conventional SQL injection attacks, as well as quite
> a bit more limited.  In the paper, he writes:
>
> "Now, whether this becomes "exploitable" in the "normal" sense, I doubt
> it... but in very
> specific and limited scenarios there may be scope for abuse, for example
> in cursor
> snarfing attacks -
> http://www.databasesecurity.com/dbsec/cursor-snarfing.pdf.
>
> In conclusion, even those functions and procedures that don?t take user
> input can be
> exploited if SYSDATE is used. The lesson here is always, always validate
> and don?t let
> this type of vulnerability get into your code. The second lesson is that
> no longer should
> DATE or NUMBER data types be considered as safe and not useful as
> injection vectors:
> as this paper has proved, they are. "
>
>
> It's definitely an interesting read, and anyone doing SQL coding should
> take a close look, IMHO.  It's particularly interesting to see how he
> alters the DATE and NUMBER data types so that they can hold SQL
> injection data.  Yet another demonstration of the importance of doing
> good input validation  -- preferably positive validation.  As long as
> you're doing input validation, I'd think there's probably no need to
> back through your code and audit it for lateral SQL injection vectors.
>
> Anyone else have a take on this new attack method?  (Note that I don't
> normally encourage discussions of specific product vulnerabilities here,
> but most certainly new categories of attacks--and their impacts on
> secure coding practices--are quite welcome.)
>
>
> Cheers,
>
> Ken
>
> -----
> Kenneth R. van Wyk
> SC-L Moderator
>
> KRvW Associates, LLC
> http://www.KRvW.com
>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
> SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
> as a free, non-commercial service to the software security community.
> _______________________________________________