RE: [PHP-DEV] Run-time taint support proposal
| From: | Andi Gutmans | Date: | Fri, 15 Dec 2006 23:23:01 +0000 |
| Subject: | RE: [PHP-DEV] Run-time taint support proposal | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-27001@lists.php.net to get a copy of this message | ||
Well the tool would point the developer at the data they have to
validate/filter. At that point the developer has to have a brain and needs
to know what he's doing with the data. Fortunately, if he has the right sets
of APIs in ext/filter which help him with this task, then it should be clear
to the average developer which ext/filter API he should choose. If we need
to improve those APIs then that can be done in parallel.
> -----Original Message-----
> From: Ilia Alshanetsky [mailto:iliaal@gmail.com] On Behalf Of
> Ilia Alshanetsky
> Sent: Friday, December 15, 2006 3:12 PM
> To: PHP internals
> Subject: Re: [PHP-DEV] 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List To
> unsubscribe, visit: http://www.php.net/unsub.php
>