Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:26988
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 66.249.82.234 as permitted sender)
DomainKey-Status: good
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer:sender;
        b=dbyaH5LXwjIpzgZ/jLESKQT10c5xHxsnHnnSTN3orIkXVPxeTJQ48uvtudCxOhbBv1viu7+cQb7H6Tt+jZUVYNWUKwqgg8HOwH3CE6Q7a3DXIUMAx+SWQ0qj1GxuEqxMMilN5m5aHw8QHvz/tXKHwsKB3N5D7tpCbNF+MsF5pt4=
In-Reply-To: <45831A87.6050301@zend.com>
References: <20061215201448.B16D8BC1AB@spike.porcupine.org> <7AE00699-23C2-4759-A50C-3D94199DA85A@prohost.org> <45831090.1000704@zend.com> <18A7CF93-7BFD-4764-847D-6C107A62875E@prohost.org> <45831A87.6050301@zend.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-ID: <EED341E1-CC7E-4573-BF76-1EE50B01C7A1@prohost.org>
Cc: Wietse Venema <wietse@porcupine.org>,
 PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: 7bit
Date: Fri, 15 Dec 2006 18:02:27 -0500
To: Stanislav Malyshev <stas@zend.com>
Sender: Ilia Alshanetsky <iliaal@gmail.com>
Subject: Re: [PHP-DEV] Run-time taint support proposal
From: ilia@prohost.org (Ilia Alshanetsky)


On 15-Dec-06, at 4:58 PM, Stanislav Malyshev wrote:

>> Ok this is better, but it will break every single application out  
>> there. I for one think that this is unacceptable.
>
> Well, initially - yes. With some tweaking like using automatic  
> filters taint-safeguarding should not be too hard though (this  
> would be one of the milestones - if we can't make it easy, the  
> whole idea is doomed). And yes, it definitely makes it unusable as  
> default production mode - but that's not the intended mode - not at  
> least until people would make writing taint-safe code the routine :)

All it means is extra work for developers with little or no tangible  
benefits. I also wonder how taint will work with the standard remove/ 
add slashes wrapper most large apps implement now a days that  
effectively modifies every input variable going into the application.

>> usually are synonymous with insecure. The biggest issue with  
>> safe_mode (and I suspect tainting as well) is the faulty  
>> assumption that if you enable it, you get instant security and you  
>> can quite being paranoid. Which leads to false sense of security  
>> and eventually getting hacked.
>
> I think the issue with safe mode is the "mark unsafe" approach -  
> which, when applied to very rich and diverse environment such as  
> PHP is bound to fail to provide comprehensive security, thus  
> leading to the problems you describe.

The job of a language is to provide tools, not arbitrary crippling  
limitation under the guise of security improvement.

>> So you reverse the problem, you'd still need to examine every  
>> function and determine which of its parameters can be tainted and  
>> which cannot.
>
> Not necessarily. If I have some obscure libWhateverFoo extension, I  
> can just say "OK, I don't know what this does, but please filter/ 
> untaint data before feeding them to it" and for that I don't even  
> need to touch the extension itself. This would not be 100% since  
> the user may just not know that passing string "pleasekillme" to  
> this extension would blow up his data center, but at least we would  
> make user consider the fact that he passes external data to the  
> extension and make decision. :)

So that means I now need to do pointless call even in instances where  
untainted data would be perfectly safe, nice.

> Also, if you talk about standard functions like strlen, demanding  
> to untaint all data before calling strlen would be rather harsh, so  
> yes, we would have to go over many functions. It is definitely not  
> a half-an-hour work, and it definitely would require some deep  
> consideration and discussion, but if we always prefer to err on the  
> safe side - and remember, we would not need any effort to be on the  
> safe side - I think we could make it work reasonable well.

safe_mode sounded like a really reasonable idea too, I would've hoped  
some lessons from past mistakes could be made.

>> and let people decide what and where things should be used. Doing  
>> automated validation is prone to error and we are almost  
>> guaranteed to never get it right.
>
> No, I do not propose to do automatic validation. I only present a  
> choice when we would ask the user to decide if the data is  
> validated enough to be untainted - we can do it as explicit as  
> requiring specific filter function call, or as implicit as making  
> many filtering functions such as htmlspecialchars functions as  
> cleaners. I tend to be somewhere in between, but that's exactly the  
> place where more feedback would be very useful.

If choice is equivalent to forcing the user to untainted all data,  
then I suppose you're right.

Ilia Alshanetsky