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@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.
> _______________________________________________
_______________________________________________
Secure Coding mailing list (SC-L) SC-L@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.
_______________________________________________
