Comments on: CORE GRASP (potential) pitfalls http://mordred.niama.net/blog/?p=120 Mon, 06 Sep 2010 06:36:38 +0000 http://wordpress.org/?v=2.5 By: Codex Securitatis » Blog Archive » Vale mundum! http://mordred.niama.net/blog/?p=120#comment-18923 Codex Securitatis » Blog Archive » Vale mundum! Thu, 21 Feb 2008 18:43:30 +0000 http://mordred.niama.net/blog/?p=120#comment-18923 [...] CORE GRASP (potential) pitfalls The Unexpected SQL Injection The Curse of Magic Quotes [...] […] CORE GRASP (potential) pitfalls The Unexpected SQL Injection The Curse of Magic Quotes […]

]]> By: ivan http://mordred.niama.net/blog/?p=120#comment-11080 ivan Fri, 24 Aug 2007 00:54:38 +0000 http://mordred.niama.net/blog/?p=120#comment-11080 Those are interesting observations but not necessarily *design* flaws. Currently can use GRASP to apply and propagate taint marks on a number of input sources (GET/POST/COOKIE/etc), there is nothing in the *design* that prevents application of the same concept to other input sources. Specifically (you outline this in our blog), Grasp can be extended to implement application of taint marks on database input. in fact, that also has a potential privacy-enhancing benefit, using that you con not only prevent you 'second order injections' but also prevent (to a certain extent) confidential DB data from leaking out disregarding of how the PHP application chooses to use it. As for an attack on the FSMs, that may or may not be possible in theory (I really haven't checked) but in practice it is quite unlikely that a normal PHP application will purposely make queries with SQL statements that have more than a few levels of recursion. Regarding the performance issues pointed out there are a few things to be said. First, that the performance optimizations of the current version are really very basic: a fully-tainted or fully-untainted string does not consume 1 taint byte per byte in the string but just a single byte while strings with mixed source bytes do consume one taint byte per string byte. There are several ways to optimize this to reduce the memory footprint and the taint-propagation runtime. Note also that the current implementation has an overhead of 1-byte per taint mark when in theory just 1-bit would be necessary, on the other hand the use of an entire byte allows for extensions to the meaning of the taint mark. Second, the 30% performance hit numbers are the *worst case scenario*, that is when all inputs are sensitive sinks and all strings have mixed sources. this is not the average case for common PHP applications. In sum, Grasp for PHP is in its infancy and there's still a lot of room for improvements, optimizations and new ideas. I would not dismiss it right away without giving it a try... Those are interesting observations but not necessarily *design* flaws.
Currently can use GRASP to apply and propagate taint marks on a number of input sources (GET/POST/COOKIE/etc), there is nothing in the *design* that prevents application of the same concept to other input sources. Specifically (you outline this in our blog), Grasp can be extended to implement application of taint marks on database input. in fact, that also has a potential privacy-enhancing benefit, using that you con not only prevent you ’second order injections’ but also prevent (to a certain extent) confidential DB data from leaking out disregarding of how the PHP application chooses to use it.

As for an attack on the FSMs, that may or may not be possible in theory (I really haven’t checked) but in practice it is quite unlikely that a normal PHP application will purposely make queries with SQL statements that have more than a few levels of recursion.

Regarding the performance issues pointed out there are a few things to be said. First, that the performance optimizations of the current version are really very basic: a fully-tainted or fully-untainted string does not consume 1 taint byte per byte in the string but just a single byte while strings with mixed source bytes do consume one taint byte per string byte. There are several ways to optimize this to reduce the memory footprint and the taint-propagation runtime. Note also that the current implementation has an overhead of 1-byte per taint mark when in theory just 1-bit would be necessary, on the other hand the use of an entire byte allows for extensions to the meaning of the taint mark. Second, the 30% performance hit numbers are the *worst case scenario*, that is when all inputs are sensitive sinks and all strings have mixed sources. this is not the average case for common PHP applications.

In sum, Grasp for PHP is in its infancy and there’s still a lot of room for improvements, optimizations and new ideas. I would not dismiss it right away without giving it a try…

]]> By: Momo http://mordred.niama.net/blog/?p=120#comment-11072 Momo Thu, 23 Aug 2007 21:14:26 +0000 http://mordred.niama.net/blog/?p=120#comment-11072 I believe in their code they mark the result of a mysql query as tainted. I believe in their code they mark the result of a mysql query as tainted.

]]>