On 12/20/06, Wietse Venema <[EMAIL PROTECTED]> wrote:
> Now, about taint mode, is it possible to leave the input filtering for
> a second and explain me what else you like to do? How do you plan to
> manage the contexts? Do you want this horrible mode 3? Or will you
> argue about input filtering, sory taint mode until next year? :)
My plan is to gather feedback from the list over the next few weeks,
and to start early 2007 with the first of many incremental steps
of design and implementation, once the over-all design is complete.
My expectation is that taint checks will be useful mostly for new
versions of PHP source code. Indiscriminate application of taint
checks on existing source code would result in many false positives.
For example, as hinted at in my proposal, code like this is certain
to be flagged:
$junk = $_GET['foo'];
if (some conditional expression involving $_GET['foo']) {
...do shell or sql command with $_GET['foo']...
}
The reason is that the compiler would not know if the conditional
expression performs data sanitization, let alone if the condition
would be appropriate for the specific shell/sql context at hand.
Two things, this is exactly the case where I would suggest to _disable
_GET/_POST/_ENV/_COOKIE/_SERVER usage and force filter_input functions
usage, for the taint mode. filter is already in place and it is
relatively easy to disable these superglobals.
Implementing "audit mode" taint checking is all the work. Adding
"enforcement mode" presents no technical challenge (change warning
into hard error), and I know people who want this. I am not too
worried that enforcement mode will be turned on indiscriminately.
As explained above, enforcement mode will not be useful unless
software was explicitly developed for run-time taint checking.
How do you plan to solve the ISP problem? when they will enable it
without any previous thoughts or analyses? Just like so many did with
safe_mode (associated with a shit load of "security" addons).
To help developers of existing software I would try to provide a
way to gradually deploy taint *checking* one source PHP file at a
time. This way, people can benefit immediately without having to
first update an entire source tree (of course taint *propagation*
would be enabled across the entire application). Gradual deployment
would require some pragma (or whatever it is called with PHP).
People concerned about the presence of such controls can simply
use ``find .. | xargs grep ..'' on the source tree.
That's the ext/filter strategy. Remove GPCES direct/raw access,
encourage the usage of the filter functions, allow a default filter
to be set (it is a kind of "let solve the common problems" attempt).
Right now, multiple untaint contexts are not in my plans, but I
would be willing to correctly maintain (bit-wise AND) the unused
seven zval bits for taint propagation, so that someone else can
build support for multiple untaint contexts on top of my work. My
tainters and untainters would simply flip all bits together, and
my taint checks would simply test all bits for non-zero.
I have the feeling you do not know ext/filter. Is it the case? If yes,
please take a look at:
http://www.php.net/filter
http://devzone.zend.com/node/view/id/1113
I'm not saying that filter is the panacee or a taint mode, but it is
already a very good start to solve the common security problems in
many php applications. If we have any taint mode, it should work
together with ext/filter.
I think I need some practical specifications/examples about your
plans. I see a lot of ideas but I fail to see the practical changes or
requirements (besides the mode 3, which sounds like a upcoming
nightmare to me).
--Pierre
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
