Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:26981
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.162 as permitted sender)
Message-ID: <45831090.1000704@zend.com>
Date: Fri, 15 Dec 2006 13:16:00 -0800
Organization: Zend Technologies
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Ilia Alshanetsky <ilia@prohost.org>
CC: Wietse Venema <wietse@porcupine.org>, 
 PHP internals <internals@lists.php.net>
References: <20061215201448.B16D8BC1AB@spike.porcupine.org> <7AE00699-23C2-4759-A50C-3D94199DA85A@prohost.org>
In-Reply-To: <7AE00699-23C2-4759-A50C-3D94199DA85A@prohost.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Run-time taint support proposal
From: stas@zend.com (Stanislav Malyshev)

> Sounds awefuly like yet another safe_mode, something that proclaims 
> security, yet being unable to provide it.

Repeating my comments on that, I think that it can be done not like 
safe_mode, if we take different approach. Namely, not "mark unsafe, 
accept otherwise" but "mark safe, deny otherwise". Meaning, first we 
separate functions into 3 categories:
1. Cleaners - can take tainted data, produce untainted data
2. Regulars - can take tainted data, produce tainted data
3. Protected - can take only untainted data
Then we mark all "unknown" function protected, then - the hard part, lot 
of work alert - go over code base and extensions and put "regular" flags 
on some basic functions (like string manipulation) and "cleaner" flag on 
some like filters. This can be done on engine level - meaning, except 
some special cases, most function would never need any code change but a 
bit in function table description. My opinion is that besides cleaners, 
most functions actually would be fine never receiving tainted data 
without prior cleaning.

Of course, it would break a lot of code, but it would be also a powerful 
way to drive people to write more secure code. E.g. if your app passes 
taint-check before deployment, it means most probably you didn't make 
the top 80% of PHP security mistakes. Of course, it won't be bulletproof 
- but no security enhancement is, and ensuring 100% secure code with 
automatic tools is quite a dream anyway.

> Unlikely to ever be the case, the overhead of taint modes is generally 
> quite significant.

This is important consideration. However, if one works with it as 
pre-deployment test step and not production, it might be less important 
- especially if combined with some kind of unit-testing and coverage 
solution.
This of course can be - and should be - combined with runtime solution 
like filtering. It is my impression that some view tainting as something 
opposed to filtering, while the correct approach would be that tainting 
complements filtering, ensuring that no data route left uncovered.

> You would need to go through some 5,000+ functions that PHP offers and 
> determine which one can and cannot receive tainted data, something that 
> virtually guarantees things will be missed, bring us back to the 
> safe_mode/open_basedir problem.

That's why - see above - I would recommend reverse approach.

> Again, many functions have different behaviors etc... Let's take an 
> example htmlspecialchars() is great against XSS but does nothing for 
> exec(), so if you htmlspecialchars a string then pass it to exec, it 
> thinks that the data is non-tainted and executes it resulting in command 
> injection.

Yep, this is a problem, thus I'm not sure htmlspecialchars should be 
always given cleaner attribute. There are a number of ways to deal with it:
1. Let the user be smart - if he thought using htmlspecialchars he 
probably is aware of filtering, so we hope he can do it right. Most of 
problems are due to lack of any filtering at all because nobody even 
thought of doing it.
2. Let the user to say us the function is really cleaning - e.g. add 
some parameter that would say "untaint" - suppsing that if one bothered 
to put this parameter one probably gave some thought to it.
3. Let the user use specific cleaner functions - like filters - so that 
we reasonably sure he knows what he's doing.

-- 
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/