Re: Run-time taint support proposal

On 12/20/06, Wietse Venema <wietse@porcupine.org> 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