Re: [SC-L] Lateral SQL injection paper
If I use Parameterized queries w/ binding of all variables, I'm 100% immune to SQL Injection. Sure. You've protected one app and transferred risk to any other process/app that uses the data. If they use that data to create dynamic sql, then what? jt -Original Message- From: Jim Manico [EMAIL PROTECTED] To: Kenneth Van Wyk [EMAIL PROTECTED] Cc: Secure Coding SC-L@securecoding.org Date: Mon, 28 Apr 2008 15:27:58 -0400 Subject: Re: [SC-L] Lateral SQL injection paper Anyone else have a take on this new attack method? If I use Parameterized queries w/ binding of all variables, I'm 100% immune to SQL Injection. In Java (for Insert/Update/etc) just use PreparedStatement + variable binding. There are similar constructs in all languages. Although the attack is cool - the defense is still the same. Grey Box Testing (code review and pen testing) will uncover all SQL Injection flaws in even the largest app in very little time. - Jim 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 dont take user input can be exploited if SYSDATE is used. The lesson here is always, always validate and dont 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. ___
Re: [SC-L] Lateral SQL injection paper
On Tue, 29 Apr 2008, Joe Teff wrote: If I use Parameterized queries w/ binding of all variables, I'm 100% immune to SQL Injection. Sure. You've protected one app and transferred risk to any other process/app that uses the data. If they use that data to create dynamic sql, then what? Let's call these using apps for clarity of the rest of this post. I think it's the fault of the using apps for not validating their own data. Here's a pathological and hopefully humorous example. Suppose you want to protect those using apps against all forms of attack. How can you protect every using app against SQL injection, XSS, *and* OS command injection? Protecting against XSS (say, by setting to gt; and other things) suddenly creates an OS command injection scenario because and ; typically have special meaning in Unix system() calls. Quoting against SQL injection \' will probably fool some XSS protection mechanisms and/or insert quotes after they'd already been stripped. As a result, the only safe data would be alphanumeric without any spaces - after all, you want to protect your user apps against whitespace, because that's what's used to introduce new arguments. But wait - buffer overflows happen all the time with long alphanumeric strings, and Metasploit is chock full of alpha-only shellcode, so arbitrary code execution is still a major risk. So we'll have to trim the alphanumeric strings to... hmmm... one character long. But, a one-character string will probably be too short for some using apps and will trigger null pointer dereferences due to failed error checking. Worse, maybe there's a buffer underflow if the using app does some negative offset calculations assuming a minimum buffer size. And what if we're providing a numeric string that the using app might treat as an array index? So, anything that looks like an ID should be scrubbed to a safe value, say, 1, since presumably the programmer doesn't allocate 0-size arrays. But wait, a user ID of 1 is often used to identify the admin in a using apps, so this would be tantamount to giving everyone admin privileges! We shouldn't accept any numbers at all. And, we periodically see issues where an attacker can bypass a lowercase-only protection mechanism by using uppercase, so we'd best set the characters to all-upper or all-lower. So, maybe the best way to be sure we're protecting using apps is to send them no data at all (which will still trigger crashes in apps that assume they'll be hearing from someone eventually). Or, barring that, you pass along some meta-data that explicitly states what protections have or have not been applied to the data you're sending - along with an integrity check of your claims. Of course, some using apps won't check that integrity and will accept bad data from anywhere, not just you, so they'll be vulnerable again, despite your best intentions. The alternate approach is to pick and choose which vulns you'll protect using apps against. But then, if you've protected a using app against SQL injection, but it moves to a non-database model instead, you've just broken your legitimate functionality. So, you're stuck with modeling which using apps are using which technologies and might be subject to which vulns. You will also need a complete model of what the using app's behaviors are, and you'll need to keep different models for each different version and operating environment. This will become brittle and quickly unmaintainable, and eventually introduce unrelated security issues as a result of that brittleness. To my current way of thinking, the two main areas of responsibility are: - for the caller to make sure that the request/message is perfectly structured and delimited, and semantically correct for what the caller is asking the callee to do. The current browser URI handler vulnerabilities, and argument injection in general, are examples of violations of this responsibility. - for the caller, given any arbitrary message/request, to prove (or enforce) that it is well-formed, to make sure that the caller has the appropriate privileges to make that message/request in the first place, and to protect itself against SQL injection when interacting with a DB, against XSS when printing out to a web page, etc. I recognize that you might not have a choice with stovepipe or legacy applications, or in proxy/firewall code that resides between two components. I feel for anyone wrestling with those problems. But, protect using apps against themselves as general advice seems fraught with peril. - Steve ___ 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.
Re: [SC-L] Lateral SQL injection paper
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. ___
Re: [SC-L] Lateral SQL injection paper
So I'd like to pull this back to a few salient points. Weirdly, some folks seem quick to dismiss the paper with a didactic shot of folks shouldn't code that way anyway which has nothing to do with the subject. 1. I think everyone on SC-L gets the idea of strong patterns and implementations, and why parameterized SQL is a good thing, and why cached queries are also a good thing (for performance, at least, and security if by doing so you enforce avoidance of EXEC()) 2. David's paper is interesting, because out in the real world people do not, and sometimes cannot, follow ideal patterns, command patterns, and or implementations that are safe. (e.g. delegation of privilege on Windows accessing the DB for security inheritance vs. the negative impact to thread pooling and process safety -- it is a real tradeoff, and *never* made on the side of security) David's paper is interesting because out in the real world people still follow many borderline unsafe practices and understanding new attack vectors is essential to assessing risk, and understanding whether refactoring, or hofixing, vs. logging, filtering, or *ignoring* the code, is the right business choice to make. David's example is more CVE instance than CWE class. -- Steven, I like the grouping of your two main abstractions below; for purpose of discussion education I like to put these together a little differently into Semantic and Syntax software security-defect buckets. I'm curious what your thoughts are (and take this offline if the response is too tangential) 1. Semantic -- I place message structure, delimiting, and all entailments of semantic conversation, including implications of use-case and business rules here, where the latter relate to enforcing specific semantic user/caller- dialogues with the application. I place callee requirement to enforce workflow, order, message structure, state and sequence, and *privilege* here. 2. Syntax -- at heart we have a data/function boundary problem, right? And most modern implementation level languages do not give us constructs to address/enforce this, so all our cluged workarounds, from stack canaries to crappy \ escaping in SQL to attempts to use of HTML named entities to encode output, fall into this grouping. I place in callee requirements everything to do with message encoding, canonicalization, buffer and case e.g.- all syntax issues, into this grouping. Now, arguably you could call a buffer or heap overflow semantic, if you argue it's privilege related, but I would say that is a result of language defects (or realities) and it still starts syntactically. Where would you put the recent URI-handler issues in this structure? Why did you specify privilege burden on the caller? I tend to leave out/ignore the caller responsiblities when I am thinking of software. This could be a bias of predominantly web-centric (and db client/server where I don't control the client) programming and design over the years. While it makes sense to enforce some syntax structure upon the caller, in general I tend to put all semantic responsibilities upon the callee, and even assume the callee should enforce some notion of syntax requirements upon the caller, and feed said back to caller. -- -- Arian J. Evans. I spend most of my money on motorcycles, mistresses, and martinis. The rest of it I squander. On Tue, Apr 29, 2008 at 9:10 AM, Steven M. Christey [EMAIL PROTECTED] wrote: On Tue, 29 Apr 2008, Joe Teff wrote: If I use Parameterized queries w/ binding of all variables, I'm 100% immune to SQL Injection. Sure. You've protected one app and transferred risk to any other process/app that uses the data. If they use that data to create dynamic sql, then what? Let's call these using apps for clarity of the rest of this post. I think it's the fault of the using apps for not validating their own data. Here's a pathological and hopefully humorous example. Suppose you want to protect those using apps against all forms of attack. How can you protect every using app against SQL injection, XSS, *and* OS command injection? Protecting against XSS (say, by setting to gt; and other things) suddenly creates an OS command injection scenario because and ; typically have special meaning in Unix system() calls. Quoting against SQL injection \' will probably fool some XSS protection mechanisms and/or insert quotes after they'd already been stripped. As a result, the only safe data would be alphanumeric without any spaces - after all, you want to protect your user apps against whitespace, because that's what's used to introduce new arguments. But wait - buffer overflows happen all the time with long alphanumeric strings, and Metasploit is chock full of alpha-only shellcode, so arbitrary code execution is still a major risk. So we'll have to trim the alphanumeric strings to... hmmm... one character long. But, a one-character string will probably be too short for some using apps
