Re: [PHP-DEV] Run-time taint support proposal
Then I see little need for having in PHP. All it means that developers
now need to write a untaint wrapper around all incoming input to shut
PHP annoyances up. I can guarantee you a tons and tons of code that
No, they need to use recommended ways to work with variables - like
filters and other untainters.
looks like this:
foreach ($_GET as $k = $v) {
$_GET[$k] = untaint($v);
}
Well, you could also write script ?php exec($_GET['command']); ?, put
it as default index page of your site and advertise it on Google. We are
not to struggle with people which want to break it. We are to help
people which want to use it. It is NOT security restriction system, it's
OS task. It is help system.
While there maybe some benefit to doing a scan and checking if a raw
user data is passed without being modified IMO it does not need to be
part of the engine. It can surely be a separate extension and offer the
All these things are interesting and may be done, but this is not
related to taint mode and its purposes. It is OK to discuss them, but
let's change the subject line then :)
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Run-time taint support proposal
Stanislav Malyshev wrote: Then I see little need for having in PHP. All it means that developers now need to write a untaint wrapper around all incoming input to shut PHP annoyances up. I can guarantee you a tons and tons of code that No, they need to use recommended ways to work with variables - like filters and other untainters. If a frequent use case is to accept some input, store it in a database and output it in HTML, then you will only get the benefit of taint once, and more importantly you will potentially be less alert to catch the potential security issues for the second. If only return values of functions could be untainted, then you would not need the context, but then it would be unpractical. The other option is to establish the best practice of always using the original untainted value when dealing with a new context. This means you would use the $_REQUEST values in order to build up the query and then when you build up the HTML. But again this may be unpractical, as you may need to massage/sanitize the input slightly. Now its not only having to escape the data for the given context, but you also have to reapply some custom business logic as to how the massaging of the data is to work. I am less concerned about the performance impact, but more about the fact that this then opens up a new class of errors, where data displayed in one context does not match the data stored in another. So by solving the security issue, you jeopardize the functionality. So my conclusion at this point is, that very frequently taint will not improve the security significantly because any given input will still be usable in an unfiltered/incorrectly filtered way for at least one context. As such it just adds code at the very core of php that provides too little of a benefit to be worthwhile. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Run-time taint support proposal
Hi, I assume its not possible to implement this as a PECL extension. As an extension it would make sense though even in this bw approach as it would then truly be an optional tool you can use like a debugger without cluttering the core. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Moving COM, Socket mhash to PECL
Wez Furlong wrote: On 12/8/06, Andi Gutmans [EMAIL PROTECTED] wrote: As far as finding a maintainer is concerned, we can check again with Wez. If he doesn't have time we should probably be able to find someone who can look into some of those bugs. Despite bugs, I've never had issues with it. I'm currently (way!) too busy to look at it, but it sounds like Frank and Pierre have volunteered some time. I'll happily review patches. --Wez. Hi Internals I am still pretty new to PHP but having spent the last couple of months reviewing the PHP code and getting to know how PHP ticks I would be happy to volunteer some time take a look at some of the outstanding issues with the COM extension. I am about to go on vacation for a couple of weeks but I will certainly have time early in 2007 to investigate some of the OPEN defects. As a couple of others (Frank and Pierre) have also volunteered time whats the best way to work this so that we make best use of our time. Should I just add add a comment to a defect when I start investigating it and then post any fixes I come up with to list for review ? Regards Andy Andy Wharmby IBM United Kingdom Limited -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Run-time taint support proposal
So my conclusion at this point is, that very frequently taint will not improve the security significantly because any given input will still be usable in an unfiltered/incorrectly filtered way for at least one context. As such it just adds code at the very core of php that provides too little of a benefit to be worthwhile. I disagree - you describe scenario where the user chooses to insufficiently or wrongly sanitize the data, and since tainting can not protect from it you say tainting is not useful. However, as I already said, tainting is not supposed to do that. It's like blaming computer OS for not preventing somebody from stealing the laptop with it :) Tainting IS NOT supposed to cure all your security problems. It is supposed to help YOU deal with some of them. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Run-time taint support proposal
Stanislav Malyshev wrote: I disagree - you describe scenario where the user chooses to insufficiently or wrongly sanitize the data, and since tainting can not protect from it you say tainting is not useful. However, as I already said, tainting is not supposed to do that. It's like blaming computer OS for not preventing somebody from stealing the laptop with it :) Tainting IS NOT supposed to cure all your security problems. It is supposed to help YOU deal with some of them. No I describe an approach to work around the lack of context aware tainting in which you always work with the initial input in each of the context. However as I describe it means you need to apply any data massaing twice in this case. This is just as error prone as forgetting about escaping user input without taint. As a result you simply trade one error class with another one, while introducing additional complexity. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Moving COM, Socket mhash to PECL
On 12/20/2006 12:26 PM, Andy Wharmby wrote: Hi Internals I am still pretty new to PHP but having spent the last couple of months reviewing the PHP code and getting to know how PHP ticks I would be happy to volunteer some time take a look at some of the outstanding issues with the COM extension. I am about to go on vacation for a couple of weeks but I will certainly have time early in 2007 to investigate some of the OPEN defects. As a couple of others (Frank and Pierre) have also volunteered time whats the best way to work this so that we make best use of our time. Should I just add add a comment to a defect when I start investigating it and then post any fixes I come up with to list for review ? Yes, that would work. Thanks. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Run-time taint support proposal
At 17:35 19/12/2006, Wietse Venema wrote: Zeev Suraski: My 2c on this piece is that tainting can be a nice helper tool to reduce the likelihood of security problems in your code. Nothing more and nothing less. I too fear the possibility of tainting becoming the new safe_mode. Outsource your security to PHP, it'll take care of it. But I think there's a way of both designing and pitching tainting so that we avoid this false perception. If we pitch tainting as a development-time only tool the points out a certain class of security mistakes, and is by no means an invisible magnetic shield that actually protects you from them - then I think it can be quite useful. Following up on an earlier suggestion in this thread, I could see at least three modes of operation: 1) Disabled. The default setting. 2) Audit mode. Report perceived problems to logfile. This can be used by developers to catch bugs, and by deployers for quality assessment (but developers please don't start screaming yet). 3) Enforcement mode. Don't allow execution past a perceived problem. Wietse, What mostly everyone is discussing here in the last few days is really an issue of perception. If we have mode 3, it means we imply that enabling magically secures your application, irregardless of whether we believe that or not. I don't like mode 3 because I don't want to set expectations that we know we can't fulfill. Tainting can help you fix certain problems in your code, and help you create more secure applications. Helping you create a more secure app means we pitch it as a development tool that helps you - it's a huge difference from saying it in itself increases the security of applications, which positions it as a safety net that protects you. Thankfully, since the implementation is pretty much identical between mode 2 and 3 (pretty much the difference would be using different error levels), so we can discuss it again once the implementation is ready. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Run-time taint support proposal
Hello, On 12/20/06, Stanislav Malyshev [EMAIL PROTECTED] wrote: output to browser, output to system (console/whatever else), sql, xml, streams, etc... all of them require special attentions. Hello, safe mode 2.0! :) Seriously, I do not think tainting is made for that - and we will have a ton of trouble trying to describe what is safe for SQL (is it for MySQL? Oracle? DB2? sqlite? a ton of other SQLs each with own quirks and quoting rules?) and what is safe for output (is it OK to output HTML tags?). Tainting mode, as I see it, is meant to achieve exactly one simple task - force you (as much as it can) to take explicit action on sanitizing the parameters before they can do any harm. I do not think it should make you use any specific way of sanitizing or check data for anything specific - this is impossible without domain-specific knowledge. This is task for filters and yes - for you as a developer. Tainting mode only makes sure for you that you do you job. That's exactly my point. Thanks to confirm it (asking what I know helps ;-) One possible way to be sure developers do their jobs (or are forced to): - set a strict default filter - disable GPCES super globals, they will not exist anymore It is one step more than the current filter approach but it helps a lot. The developers have to worry about GPCES as they are not available anymore, not outside the filter functions (a big break, but a necessary one imho, dreaming...). I do not want the mode 3, for the reasons I explained earlier. I also Actually, I do. Especially if I had some legacy non-filtering application which I wanted to secure. I would prefer to break it hard and then assemble the pieces in the correct way, rather than play find-the-next-hole. Same comment as before, drop all GPCES usages. This is a typical situtation, something like what Rasmus described in his post about Y! policy. think many developers have the same reasons against it. It will be enabled by default by many ISP and will bring back the pain of safe_mode. It is not like safe mode, and I explained about dozen times what is the main difference. Please read it. We are going in circles here. I was not clear, I did not say it is like safe_mode: I said that this mode 3 will bring the same amount of WTF than safe_mode in production servers (ISP). --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: zoe
I've been looking at the php tests and would like to be able to contribute more tests for basic PHP functions to help increase the test coverage and prevent regressions when code is changed. I don't know how granular the CVS access controls are so am not sure what is possible. I've been working from gcov.phpt.net and looking for gaps in coverage - so far just /ext/standard/levenshtein.c and ext/standard/assert.c. It would also be helpful if I could maintain update the documentation if there is agreement that something is working as designed but not as documented.This was discussed briefly with Andi G and Zeev who suggested applying. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Run-time taint support proposal
Pierre wrote: I do not want the mode 3, for the reasons I explained earlier. I also Actually, I do. Especially if I had some legacy non-filtering application which I wanted to secure. I would prefer to break it hard and then assemble the pieces in the correct way, rather than play find-the-next-hole. Same comment as before, drop all GPCES usages. This is a typical situtation, something like what Rasmus described in his post about Y! policy. Except we don't drop GPCES (well we do drop $_COOKIE, but for other reasons) which means that existing apps work fine. Dropping GPCES means it becomes very hard to run existing code. If the default filter is strict enough, I don't see the point in dropping those. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Run-time taint support proposal
On 12/20/06, Rasmus Lerdorf [EMAIL PROTECTED] wrote: Pierre wrote: I do not want the mode 3, for the reasons I explained earlier. I also Actually, I do. Especially if I had some legacy non-filtering application which I wanted to secure. I would prefer to break it hard and then assemble the pieces in the correct way, rather than play find-the-next-hole. Same comment as before, drop all GPCES usages. This is a typical situtation, something like what Rasmus described in his post about Y! policy. Except we don't drop GPCES (well we do drop $_COOKIE, but for other reasons) which means that existing apps work fine. Dropping GPCES means it becomes very hard to run existing code. If the default filter is strict enough, I don't see the point in dropping those. Indeed, we have to keep them. It is somehow something I like to have (optionally), to be able to disable them, just like JIT or disable_functions. As a rule enforcement, it cannot be done in a better way :-). --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Run-time taint support proposal
As a casual observer of this thread, this was the explanation that really clarified the prior posts for me. I think having option 3 (enforcement mode) would be great, however, if everybody is tripping up on mis-managing expectations then I'd suggest a play on semantics by calling it something else e.g. 'force filter attempts'. Doing this is trivial but how you name it can go a long way to how it is perceived...not to mention continuing the tradition of great comments in the php.ini. --Tony Zeev Suraski wrote: Wietse, What mostly everyone is discussing here in the last few days is really an issue of perception. If we have mode 3, it means we imply that enabling magically secures your application, irregardless of whether we believe that or not. I don't like mode 3 because I don't want to set expectations that we know we can't fulfill. Tainting can help you fix certain problems in your code, and help you create more secure applications. Helping you create a more secure app means we pitch it as a development tool that helps you - it's a huge difference from saying it in itself increases the security of applications, which positions it as a safety net that protects you. Thankfully, since the implementation is pretty much identical between mode 2 and 3 (pretty much the difference would be using different error levels), so we can discuss it again once the implementation is ready. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Query on assert_options() api
Hi Internals
A colleague of mine is currently working on creating new test
cases to improve the coverage of the PHP test cases and whilst
attempting to
write new tests for the assert extension hit on a problem when
attempting to query the current setting of ASSERT_CALLBACK. using the
assert_options() api.
With the following simple testcase :
?php
function andy()
{
echo andy called\n;
}
$o = assert_options(ASSERT_CALLBACK, andy); /* SET */
$n = assert_options(ASSERT_CALLBACK); /* INQ */
echo old setting is $o\n;
echo new setting is $n\n;
?
The expected result was that the old (if any) and new setting of the
callback function name would be displayed but the actual results was
old setting is 1
new setting is 1
Looking at the code this is no surprise as the code in assert.c which
processes these requests unconditionally returns with RETURN_TRUE.
For all other assert options other than assert_options() function
returns the old value of the specified option as documented in the PHP
manual.
Further investigation uncovered that the code actually did behave in the
way we expected until it was changed to accept the array($obj,
methodname)
syntax back in July 2001 (revision 1.32 of assert.c). At this time the
return was changed to be unconditionally TRUE.
Unfortunately this makes writing a test case to query the current
setting of the ASSERT_CALLBACK option impossible as assert_options() no
longer returns
any useable information for this option, i.e to code a testcase as
above that sets a value and then checks its set as expected.
If the code is modified as in the attached patch to instead return the
ZVAL for the ASSERT_CALLBACK option then we are able create the new
testcase to
verify the assert_options() api. However, I am concerned there is a
good reason this was not done when the code was changed back in 2001.Can
anyone think
of a good reason why returning the zval on this api is not a good idea ?
Any comments on my proposed fix appreciated.
Regards
Andy
Andy Wharmby
IBM United Kingdom Limited
--- assert.c2006-12-03 17:30:54.0 +
+++ assert.c.new2006-12-20 14:55:03.259056200 +
@@ -286,6 +286,11 @@
break;
case ASSERT_CALLBACK:
+ if (ASSERTG(callback) != NULL) {
+ RETVAL_ZVAL(ASSERTG(callback), 1, 0);
+ } else {
+ RETVAL_NULL();
+ }
if (ac == 2) {
if (ASSERTG(callback)) {
zval_ptr_dtor(ASSERTG(callback));
@@ -293,7 +298,7 @@
ASSERTG(callback) = *value;
zval_add_ref(value);
}
- RETURN_TRUE;
+ return;
break;
default:
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Unicode support for *printf()
Committed. On Dec 19, 2006, at 6:36 PM, Matt Wilmas wrote: Hi Andrei, Yeah, I see the patch you committed also included the changes that were made since my reply yesterday... I've attached a patch that removes a few lines that aren't present in the non-Unicode version. Matt - Original Message - From: Andrei Zmievski Sent: Tuesday, December 19, 2006 Is this better? -Andrei On Dec 18, 2006, at 6:22 PM, Matt Wilmas wrote: Hi Andrei, Just a couple things I noticed in _appenddouble... In the first switch (), 'F' is being changed to 'f', and in the second switch, 'F' needs to be moved down with 'f'. Those changes were just made in v1.89 of the file. Matt formatted_print.diff.txt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Run-time taint support proposal
At 19:33 20/12/2006, Tony Bibbs wrote: As a casual observer of this thread, this was the explanation that really clarified the prior posts for me. To give credit where credit's due, it was Wietse's post, not mine! Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Dumping support for Windows 98 and Windows ME
Hi all, In the spirit of dumping Win95 support in PHP 5, I'd like to officialy dump Windows 98ME support from this point onwards. We are sticking to old Windows APIs because of this support which doesn't make much sense considering that Microsoft has stopped supporting those platforms six months ago (http://www.microsoft.com/windows/support/endofsupport.mspx). So I see no reason for us to support Micorsoft customers better than they do :) Those who are stuck on those versions should just stick to the versions up to PHP 5.2.0. They are not getting Windows updates, so why should they get PHP updates? Unless anyone disagrees with this, we'll go ahead with this. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dumping support for Windows 98 and Windows ME
Hello Andi, On 12/20/06, Andi Gutmans [EMAIL PROTECTED] wrote: Unless anyone disagrees with this, we'll go ahead with this. We are waiting since months, go ahead :) --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dumping support for Windows 98 and Windows ME
Andi Gutmans wrote: In the spirit of dumping Win95 support in PHP 5, I'd like to officialy dump Windows 98ME support from this point onwards. We are sticking to old Windows APIs because of this support which doesn't make much sense considering that Microsoft has stopped supporting those platforms six months ago (http://www.microsoft.com/windows/support/endofsupport.mspx). So I see no reason for us to support Micorsoft customers better than they do :) Those who are stuck on those versions should just stick to the versions up to PHP 5.2.0. They are not getting Windows updates, so why should they get PHP updates? As the prime win32 mover at httpd, I'd say I wholeheartedly agree. APR, the portability layer, is moving in this same direction. THAT SAID... please be prepared for hoots and howls, you will be surprised to discover how many Win98SE boxes keep going, and going, and going. Because there are better free/open operating systems solutions out there, over win32, I no longer hold the opinion that 'forcing' a minimum baseline of WinNT 4 SP6 or WinNT 5 (2000) is terribly unreasonable. Let those who haven't/won't upgrade, due to cost, seek out a better solution. Bill -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
