Re: Run-time taint support proposal

On 15-Dec-06, at 6:06 PM, Wietse Venema wrote:

Ilia Alshanetsky:

On 15-Dec-06, at 5:19 PM, Wietse Venema wrote:

Ilia Alshanetsky:

That means an additional element to a struct that has thousands of instances in most scripts, this will be the first overhead caused by the memory footprint increase.

There is no need for that.

<       zend_uchar is_ref;

---

      zend_uchar is_ref:7;
      zend_uchar taint_flag:1;

Perhaps a working implementation will be convincing. I offer to do the work, other people lose nothing except the possibility that they will be proven right.

By all means :-) I suppose by making taint_flag 1 bit, you are assuming taint is purely black and white and that all untaint functions will secure data against all forms of usage.

If the default fail-close security policy is no function receives tainted input unless explicitly stated otherwise, then one bit suffices. That is actually the easiest part.

And here is your first exploit, let's say we say mysql_real_escape_string() takes tainted data and makes it untainted, what happens when this "safe" data is passed to exec(). You are going to need to deal with different levels of taint-untainted and 1 bit is not going to give you that flexibility. You are going to need an int/long, maybe even a long long. Ilia Alshanetsky