Hi,
I think I have a solution that would allow user streams in PHP 6 and
still satisfy paranoid hosters.
First, let me clarify what I see as the assumed problem, so that if I
have missed something, you will correct my assumption:
My assumption:
The point of allow_url_include/allow_url_fopen is to prevent stupid
remote execution vulnerabilities like:
<?php
include $_GET['dumb'];
?>
allow_url_(include|fopen) is not intended to prevent users from
accessing remote sites, as it is still possible through fsockopen() and
other methods to access the outside world. A firewall is the only way
to truly prevent access to the outside world.
Note that the stream wrapper file:// is a local stream wrapper. Remote
stream wrappers access the outside world such as http:// ftp:// and
gopher://
The problem:
Because there is no way to be sure that a userspace stream is not
remote, all userspace streams are marked as remote and so
allow_url_(include|fopen) applies to them. As such, because
allow_url_(include|fopen) are disabled by default in PHP 6, this will
effectively kill userspace streams for anything but niche usage.
The solution:
Add a new function: stream_wrapper_set_local()
This function would be used to mark a registered user stream wrapper as
being local, which would allow it to be used. It would not affect
internal stream wrappers.
Why would this be any different? The point of the allow_* options is to
make it more difficult to write insecure code. This would still apply,
as a user would have to explicitly register a stream wrapper as being
local. This way, our example code:
<?php
include $_GET['dumb'];
?>
would still fail on all the wrappers it should fail on. The malicious
use of a userspace stream wrapper that is remote would still fail unless
the user explicitly marked it as local.
Paranoid hosters could simply put stream_wrapper_set_local() into the
disable_functions option.
Comments?
Greg
I don't think this is a good idea. If you need to access external
data use fsockopen or stream code or even cURL. Creating filters just
to add bypasses for them seems silly to me.
Hi,
I think I have a solution that would allow user streams in PHP 6 and
still satisfy paranoid hosters.First, let me clarify what I see as the assumed problem, so that if I
have missed something, you will correct my assumption:My assumption:
The point of allow_url_include/allow_url_fopen is to prevent stupid
remote execution vulnerabilities like:<?php
include $_GET['dumb'];
?>allow_url_(include|fopen) is not intended to prevent users from
accessing remote sites, as it is still possible throughfsockopen()
and
other methods to access the outside world. A firewall is the only way
to truly prevent access to the outside world.Note that the stream wrapper file:// is a local stream wrapper.
Remote
stream wrappers access the outside world such as http:// ftp:// and
gopher://The problem:
Because there is no way to be sure that a userspace stream is not
remote, all userspace streams are marked as remote and so
allow_url_(include|fopen) applies to them. As such, because
allow_url_(include|fopen) are disabled by default in PHP 6, this will
effectively kill userspace streams for anything but niche usage.The solution:
Add a new function: stream_wrapper_set_local()
This function would be used to mark a registered user stream
wrapper as
being local, which would allow it to be used. It would not affect
internal stream wrappers.Why would this be any different? The point of the allow_* options
is to
make it more difficult to write insecure code. This would still
apply,
as a user would have to explicitly register a stream wrapper as being
local. This way, our example code:<?php
include $_GET['dumb'];
?>would still fail on all the wrappers it should fail on. The malicious
use of a userspace stream wrapper that is remote would still fail
unless
the user explicitly marked it as local.Paranoid hosters could simply put stream_wrapper_set_local() into the
disable_functions option.Comments?
Greg
--
Ilia Alshanetsky
I think it is a very good solution.
IMO, we don't have to go further in protecting the user against himself, even if allowing to switch the local/remote flag on streams from user space won't please to everybody...
Francois
The problem:
Because there is no way to be sure that a userspace stream is not
remote, all userspace streams are marked as remote and so
I think that's the first mistake. Marking all streams remote because
some of them could do remote access is like refusing to execute all user
code because some of it could contain security holes. And it doesn't
help - as far as I can see, these precautions still don't catch UNC
remote access (\1.2.3.4\myshare\myfile.php) on Windows.
allow_url_(include|fopen) applies to them. As such, because
allow_url_(include|fopen) are disabled by default in PHP 6, this will
Disabling allow_url_fopen by default is the second mistake. What's wrong
with it? Wasn't the sole reason for having allow_url_include to allow
url_fopen work while protecting includes? Oh yes, somebody could say
fopen+eval. So, somebody could also say curl_open+eval, so what?
The solution:
Add a new function: stream_wrapper_set_local()
Well, it could solve the problem, however it's a very perverted way of
doing things - erecting "security measure" that should be removed for
any real use. The whole reason for using this function would be to use
that stream in the context of the include - i.e. if you don't include,
you don't need it. But if you don't include, you don't care for
allow_url_include on user streams either, so effectively having this
function would be the same as reverting the decision about marking all
user streams remote - just instead of PHP every user of the user streams
would have to do it manually. Security-wise it would be exactly the
same, hassle-wise - much worse.
Why would this be any different? The point of the allow_* options is to
make it more difficult to write insecure code. This would still apply,
as a user would have to explicitly register a stream wrapper as being
local. This way, our example code:
He'd have to register it regardless of if it is local or remote -
meaning, every time you use stream for include context you have to mark
it as local. Since if it's not used for include it doesn't matter what
it is marked, it's the same as saying "every time you use the stream you
have to mark it", or alternatively "all used user streams should be
marked". Now, you probably won't define a stream unless you intend to
use it, so it becomes "all defined user streams should be marked as
local". Isn't it the same as not marking them remote from start?
Paranoid hosters could simply put stream_wrapper_set_local() into the
disable_functions option.
Maybe it's better to suggest paranoid hosters to disable user stream
functions? Or add user_streams_are_local=0 for them.
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Stanislav Malyshev wrote:
allow_url_(include|fopen) applies to them. As such, because
allow_url_(include|fopen) are disabled by default in PHP 6, this willDisabling allow_url_fopen by default is the second mistake. What's wrong
with it? Wasn't the sole reason for having allow_url_include to allow
url_fopen work while protecting includes? Oh yes, somebody could say
fopen+eval. So, somebody could also say curl_open+eval, so what?
I'm on a really crappy connection in China right now, so I haven't read
the whole thread, but this caught my eye. Since when is allow_url_fopen
disabled by default? It certainly isn't in my PHP6 checkout from a
couple of days ago. And it shouldn't be disabled by default.
-Rasmus
I think the problem could be solved this way:
- allow_url_include and allow_url_fopen renamed to allow_remote_include
and allow_remote_fopen (not really necessary, just much cleaner, if you
don't like it, ignore it for now). - By default, allow_remote_inclue=0, allow_remote_fopen=1
- Stream can be of three types - remote, local and user/local.
- User streams can be declared when registered as either remote or
user/local, remote being the default. - When operation on user/local stream is run, allow_remote_fopen is
disabled if allow_remote_include was disabled.
Thus, if somebody doesn't mark the stream local, it's remote and behaves
just like http://. If it is marked as local, it can be used in includes
under allow_remote_include=0, however it could not do things like:
function stream_open($path, $mode, $options, &$opened_path)
{
$this->file = fopen($path);
}
and thus make the local include work with remote files.
This would require following changes:
- Adding optional parameter to stream registration functions.
- Some tweaking in user streams module to toggle allow_remote_fopen for
user/local streams.
What do you think?
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
oh, and I forgot another thing:
- Have some function like stream_is_remote() which could check URL for
remote-ness,
so that the responsible stream wrapped would not rely on fopen erroring out.
I couldn't locate such function, so if it isn't there it should be added.
I think the problem could be solved this way:
- allow_url_include and allow_url_fopen renamed to allow_remote_include
and allow_remote_fopen (not really necessary, just much cleaner, if you
don't like it, ignore it for now).- By default, allow_remote_inclue=0, allow_remote_fopen=1
- Stream can be of three types - remote, local and user/local.
- User streams can be declared when registered as either remote or
user/local, remote being the default.- When operation on user/local stream is run, allow_remote_fopen is
disabled if allow_remote_include was disabled.
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Stanislav Malyshev wrote:
oh, and I forgot another thing:
- Have some function like stream_is_remote() which could check URL for
remote-ness,
so that the responsible stream wrapped would not rely on fopen erroring
out.
I couldn't locate such function, so if it isn't there it should be added.I think the problem could be solved this way:
- allow_url_include and allow_url_fopen renamed to
allow_remote_include and allow_remote_fopen (not really necessary,
just much cleaner, if you don't like it, ignore it for now).- By default, allow_remote_inclue=0, allow_remote_fopen=1
- Stream can be of three types - remote, local and user/local.
- User streams can be declared when registered as either remote or
user/local, remote being the default.- When operation on user/local stream is run, allow_remote_fopen is
disabled if allow_remote_include was disabled.
This is cleaner than my suggestion, I like it. It would also be very
easy to implement.
Greg
According to the plan below, attached is the patch that restricts user
streams from executing dangerous operations inside include context.
Please comment.
I think the problem could be solved this way:
- allow_url_include and allow_url_fopen renamed to
allow_remote_include and allow_remote_fopen (not really necessary,
just much cleaner, if you don't like it, ignore it for now).- By default, allow_remote_inclue=0, allow_remote_fopen=1
- Stream can be of three types - remote, local and user/local.
- User streams can be declared when registered as either remote or
user/local, remote being the default.- When operation on user/local stream is run, allow_remote_fopen is
disabled if allow_remote_include was disabled.
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
According to the plan below, attached is the patch that restricts user
streams from executing dangerous operations inside include context.
Please comment.
Forgot to mention - the patch is against HEAD and does not include
changing names of INI/structure fields, though it might be a good idea too.
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Hello Stanislav,
why then not have ini as follows:
allow_url_(fopen|include)_(local|user|remote)
That is 6 for the six cases - or is that too easy?
We could also have the _remote case be an alias to keep the old style
and have full consistency.
best regards
marcus
Wednesday, May 30, 2007, 2:16:30 AM, you wrote:
According to the plan below, attached is the patch that restricts user
streams from executing dangerous operations inside include context.
Please comment.
I think the problem could be solved this way:
- allow_url_include and allow_url_fopen renamed to
allow_remote_include and allow_remote_fopen (not really necessary,
just much cleaner, if you don't like it, ignore it for now).- By default, allow_remote_inclue=0, allow_remote_fopen=1
- Stream can be of three types - remote, local and user/local.
- User streams can be declared when registered as either remote or
user/local, remote being the default.- When operation on user/local stream is run, allow_remote_fopen is
disabled if allow_remote_include was disabled.
Best regards,
Marcus
why then not have ini as follows:
allow_url_(fopen|include)_(local|user|remote)
That is 6 for the six cases - or is that too easy?
Because there's no need for 6 settings. Also, what
allow_url_include_local is supposed to mean? Why would one prohibit
local file access and local includes?
The whole idea of the patch is to make user streams behave more like
built-in streams while ensuring that random mistakes in user stream
implementation (such as forgetting to check if the URL is local) would
not lead the stream to include remote code.
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Attached is second version of the patch implementing the security model
below. The difference to previous version is that the optional argument
for stream_wrapper_register is now an integer flag, which allows to
extend it in the future.
Any comments/objections?
I think the problem could be solved this way:
- By default, allow_remote_inclue=0, allow_remote_fopen=1
- Stream can be of three types - remote, local and user/local.
- User streams can be declared when registered as either remote or
user/local, remote being the default.- When operation on user/local stream is run, allow_remote_fopen is
disabled if allow_remote_include was disabled.
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
2007/5/18, Greg Beaver greg@chiaraquartet.net:
<?php
include $_GET['dumb'];
?>
What about permanently removing this (mis) "feature" ?? , Im yet to
hear any valid reason or example to continue to permit this remote
include thingy, all examples I have seen are bogus and broken.. does
anyone really think there are valid use cases ? (note that Im talking
about include* and require* only ;) )
What about permanently removing this (mis) "feature" ?? , Im yet to
You can't remove this feature, unless you write separate file access
layer for include and for the rest of the language. You can permanently
set allow_url_include to 0, but if it's 0 by default it's more/less the
same.
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
2007/5/18, Greg Beaver greg@chiaraquartet.net:
<?php
include $_GET['dumb'];
?>What about permanently removing this (mis) "feature" ?? , Im yet to
hear any valid reason or example to continue to permit this remote
include thingy, all examples I have seen are bogus and broken.. does
anyone really think there are valid use cases ? (note that Im talking
about include* and require* only ;)
How about installing a whole application suite by telling people. Hey
run this:
$ php -d allow_url_include=1 -r "include 'http://pear.php.net/go-pear';";
Useful? I think so.
Edin
2007/5/18, Greg Beaver greg@chiaraquartet.net:
<?php
include $_GET['dumb'];
?>What about permanently removing this (mis) "feature" ?? , Im yet to
hear any valid reason or example to continue to permit this remote
include thingy, all examples I have seen are bogus and broken.. does
anyone really think there are valid use cases ? (note that Im talking
about include* and require* only ;) )
There are some limited valid uses on an Intranet where a single master
source of some high-level include files is maintained on a separate
server...
That's pretty trivial to work-around with rsync or similar, though, so
I don't know that this is a deal-breaker for anybody...
There are some folks who might have a valid white-list approach with
PCRE for what they include, and pass it around as a variable, however.
Especially those who are into highly-dynamic languages, with zillions
of include files.
I'm not sure how you'd get rid of only $_GET and friends but keep any
regular old variables without something like the "taint" model that
was proposed and, I think, still being worked on.
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
2007/5/18, Greg Beaver greg@chiaraquartet.net:
Hi,
I think I have a solution that would allow user streams in PHP 6 and
still satisfy paranoid hosters.
s/paranoid/sane/g
as it is still possible through
fsockopen()and
other methods to access the outside world.
with a "tiny" :) difference, remote connections fsockopen() and
friends will not parse and interprate PHP code directly unless the
user eval() it..:)
A firewall is the only way
to truly prevent access to the outside world.
yes, agree, but the remote "include" feature just make unintentional
mistakes easy, if you look real life code that uses the url_include
thingy.. in the 99% they meant readfile() ..ohh but what about fopen +
eval ? well in that case the user will always want to eval()
explicitely and there is nothing that PHP can do to avoid that
stupiduty..
I think I have a solution that would allow user streams in PHP 6 and
still satisfy paranoid hosters.s/paranoid/sane/g
Sane hosters do not rely on general-purpose language to provide
security, they use OS and hardware designed for exactly that purpose. ;)
yes, agree, but the remote "include" feature just make unintentional
There's no distinct remote include feature. There's remote file access
feature that can be used in the context of the include.
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Christian,
I suggest that you simply stop arguing with PHP developers about
security issues.
The problem is that they don't understand them. They are too arrogant.
They actually
believe they know everything better.
In such a situation there is only one healing. Stop giving them tips and
let them
run against walls again and again. With the last X releases and the
again and again
introduced BC breaks and additional security bugs they have pissed off
already
many of their users.
At the moment they are very predictable. You send them a security bug
and first
they try to tell you that you are totally wrong (because you made a
mistake by
sending them a non working example). Then you recommend a way to fix it.
But don't expect that they are fixing it the way you tell them...
They will do something else to prove that they "outsmarted" you. Yeah
guess what
their fix is of course not a solution and as usual fixes just one of the
symptoms.
Stefan Esser
At the moment they are very predictable. You send them a security bug
and first they try to tell you that you are totally wrong (because
you made a
I wonder if you actually aware of the fact that there's no such single
entity as "PHP developers" and each of them is entirely different living
human? And these humans sometimes are in disagreement and some of them
are wrong? And then the thing called "discussion" happens and it's not
always about conspiring against certain security researchers? There's no
"them". Try to think about it for a minute.
They will do something else to prove that they "outsmarted" you. Yeah
I wonder also if you are aware of the fact that not everybody is
concerned with the question of who outsmarts whom here but some actually
more concerned about fixing actual problems?
guess what their fix is of course not a solution and as usual fixes
just one of the symptoms.
If you are aware of some security problems in current PHP sources you
are as always welcome to report them and they will be fixed. I think
everybody here as always are thankful for any help we can get.
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
I wonder if you actually aware of the fact that there's no such single
entity as "PHP developers" and each of them is entirely different living
human? And these humans sometimes are in disagreement and some of them
are wrong? And then the thing called "discussion" happens and it's not
always about conspiring against certain security researchers? There's
no "them". Try to think about it for a minute.
Yes I think you do not need to repeat that there is no such thing as a
PHP leadership.
The reason number one why PHP development is chaotic and unprofessional.
Stefan Esser
Yes I think you do not need to repeat that there is no such thing as a
PHP leadership.
I don't need to repeat it because I never said that and it's not true.
There's difference between leadership and not having disagreement or
discussion, even if some fail to see it.
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Stanislav Malyshev schrieb:
Yes I think you do not need to repeat that there is no such thing as a
PHP leadership.I don't need to repeat it because I never said that and it's not true.
There's difference between leadership and not having disagreement or
discussion, even if some fail to see it.
Everyone watching the PHP internals list can see how true it is. One war
after another, because some PHP developers are more equal than others.
It depends on the "status" of the maintainers if beta/alpha extensions
are merged into the core. (ext/filter) or
if they are refused.
The whole filter problematic is still unsolved. The filter hooks were
still not moved into php_register_variable_ex so that they
cannot be bypassed by mistake of a 3rd party PHP extension that
implements another POST content-type.
And ext/filter still does no daisy chaining of the filter hooks...
Let's not forget that the typical internals discussion is that some Zend
employee steps in and believes he is a leader and makes the decisions.
(Hello Antony). And this happens because there is NO leader that steps
in. (Hello PHP Group)
Stefan Esser
Everyone watching the PHP internals list can see how true it is. One war
after another, because some PHP developers are more equal than others.
What you see as a war, other see as a discussion. I think if you tried
viewing it as figuring out common solution and discussing options and
not combat it would make sense to you too, probably.
The whole filter problematic is still unsolved. The filter hooks were
still not moved into php_register_variable_ex so that they
cannot be bypassed by mistake of a 3rd party PHP extension that
implements another POST content-type.
And ext/filter still does no daisy chaining of the filter hooks...
I think it would be better to describe the problems you see with filters
in separate email and in more detail, since I have a feeling not
everybody would be following this discussion closely.
Let's not forget that the typical internals discussion is that some Zend
employee steps in and believes he is a leader and makes the decisions.
I have a feeling that this somehow implies being Zend employee
disqualifies person from discussing matters and making decisions. One
weird position, I'd say.
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Stanislav Malyshev schrieb:
What you see as a war, other see as a discussion. I think if you tried
viewing it as figuring out common solution and discussing options and
not combat it would make sense to you too, probably.
Maybe I read a different internals list. Just read the World vs. Pierre
thread. While some things in there are quite true, it is completely
agressive towards Pierre.
I think it would be better to describe the problems you see with
filters in separate email and in more detail, since I have a feeling
not everybody would be following this discussion closely.
And I think I repeated myself often enough.
I have a feeling that this somehow implies being Zend employee
disqualifies person from discussing matters and making decisions. One
weird position, I'd say.
No it implies that Zend employees believe they have a special status
because they work for Zend. Just look at Antony and his aggressive
attitude to dictacte what others should do or should not do. Recent
example: Antony vs. Pierre.
Antony is very fast with assigning bugs to persons that have nothing
todo with them.
I believe there is still a bug assigned to me because in Antony's world
I am responsible for it, while infact
my commit was in a version AFTER the one the problem was reported for.
Stefan Esser
And I think I repeated myself often enough.
So here we go again - a lot of time spent to write lengthy emails about
how bad this and that person or PHP Group as a whole is, or to hint
about multiple problems without getting into details - and when it comes
to details - no, that's no fun anymore. Should we open
php-shrink@lists.php.net instead of internals@lists.php.net?
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Stanislav Malyshev schrieb:
So here we go again - a lot of time spent to write lengthy emails
about how bad this and that person or PHP Group as a whole is, or to
hint about multiple problems without getting into details - and when
it comes to details - no, that's no fun anymore. Should we open
php-shrink@lists.php.net instead of internals@lists.php.net?
Stanislav,
you are a liar. Enough said.
Stefan Esser
Antony is very fast with assigning bugs to persons that have nothing
todo with them.
I believe there is still a bug assigned to me because in Antony's
world
I am responsible for it, while infact
my commit was in a version AFTER the one the problem was reported for.
Perhaps he just thought you were best-qualified to fix the bug, since
you obviously understood what was going on well enough to have
commited code recently.
I mean, he's got to assign to to somebody, or it won't ever get done.
If you can't do it, re-assign it to somebody, or let him know you
can't do the task, and he'll pass the buck on to somebody else.
Why am I getting into this?...
Look, guys, you're all working your asses off, and you all have great
ideas about what should happen and what's best for PHP.
And they don't always match up.
But this constant sniping and flame-war stuff is not really conducive
to anybody getting any work done, volunteer or otherwise.
And it sure doesn't look good to the casual reader who's maybe
interested in starting to work on PHP CVS source...
Imagine you went to a job interview, and the employees are having a
huge pointless flame-fest argument right outside.
You gonna want to WORK in that environment?
I think not.
Can you all try to set aside the personality conflicts and focus just
on the facts of what needs doing, and why, and discussions about what
makes PHP better?...
Whatever personal problems exist between developers, these kinds of
flame-wars are pretty ridiculous, imho...
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
Why is it that you all fight worse than my 3rd year old cousins? I
don't hold any authority or figure what so ever, but I watch
internals as a developer to be forewarned, but really, all I see is a
bunch of children fighting with each other.
Stefan has made contributions and has helped... He's right about
certain things; Yet why everyone is attacking everyone is beyond me.
Are the other OS languages like this? Python, Ruby, Perl? Do they
all experience the constant fighting and arguing and flaming that
goes on the php internals list?
Maybe there should be clearer rules for how bugs get assigned (I like
the idea of only assigning the bug once you start to work on a
solution.... that ways it's left for whoever has the time to fix it).
Anyways, Aren't we all adults? Can't we communicate like it and stop
trying to take each others legs out?
Antony is very fast with assigning bugs to persons that have nothing
todo with them.
I believe there is still a bug assigned to me because in Antony's
world
I am responsible for it, while infact
my commit was in a version AFTER the one the problem was reported
for.Perhaps he just thought you were best-qualified to fix the bug, since
you obviously understood what was going on well enough to have
commited code recently.I mean, he's got to assign to to somebody, or it won't ever get done.
If you can't do it, re-assign it to somebody, or let him know you
can't do the task, and he'll pass the buck on to somebody else.Why am I getting into this?...
Look, guys, you're all working your asses off, and you all have great
ideas about what should happen and what's best for PHP.And they don't always match up.
But this constant sniping and flame-war stuff is not really conducive
to anybody getting any work done, volunteer or otherwise.And it sure doesn't look good to the casual reader who's maybe
interested in starting to work on PHP CVS source...Imagine you went to a job interview, and the employees are having a
huge pointless flame-fest argument right outside.You gonna want to WORK in that environment?
I think not.
Can you all try to set aside the personality conflicts and focus just
on the facts of what needs doing, and why, and discussions about what
makes PHP better?...Whatever personal problems exist between developers, these kinds of
flame-wars are pretty ridiculous, imho...--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
This one time, at band camp, Stefan Esser sesser@hardened-php.net wrote:
The whole filter problematic is still unsolved. The filter hooks were
still not moved into php_register_variable_ex so that they
cannot be bypassed by mistake of a 3rd party PHP extension that
implements another POST content-type.
And ext/filter still does no daisy chaining of the filter hooks...
stop whining and submit a patch
Kevin
--
"Democracy is two wolves and a lamb voting on what to have for lunch.
Liberty is a well-armed lamb contesting the vote."
stop whining and submit a patc
Stop flooding my inbox with your unqualified comments.
You can write the patch yourself, can you?
Or can't you? Then shut the fuck up.
Stefan Esser
This one time, at band camp, Stefan Esser sesser@hardened-php.net wrote:
Stop flooding my inbox with your unqualified comments.
You can write the patch yourself, can you?
Or can't you? Then shut the fuck up.
I'm not the one whining about nothing being done.
This constant stream of dribble about PHP not being the way you
want it is pathetic.
You seem to typify the open source community in a nutshell.
"WAAAAAA ITS NOT THE WAY I WANT IT!!! SOMEBODY FIX IT!!!"
The time and effort you have spent on this thread could really have
been used for more constructive purposes, unless the purpose of these
posts is to inflate your ego and that all should bow to your demands
on you you believe the PHP project should be adminstered, whilst
deriding the good work and intensions of others.
grow up.
Kevin
--
"Democracy is two wolves and a lamb voting on what to have for lunch.
Liberty is a well-armed lamb contesting the vote."
Dear Kevin,
you are just ridiculous. Educate yourself WHO is responsible for
improved PHP security.
Stefan Esser
This one time, at band camp, Stefan Esser sesser@hardened-php.net wrote:
Stop flooding my inbox with your unqualified comments.
You can write the patch yourself, can you?
Or can't you? Then shut the fuck up.I'm not the one whining about nothing being done.
This constant stream of dribble about PHP not being the way you
want it is pathetic.You seem to typify the open source community in a nutshell.
"WAAAAAA ITS NOT THE WAY I WANT IT!!! SOMEBODY FIX IT!!!"The time and effort you have spent on this thread could really have
been used for more constructive purposes, unless the purpose of these
posts is to inflate your ego and that all should bow to your demands
on you you believe the PHP project should be adminstered, whilst
deriding the good work and intensions of others.grow up.
Kevin
If you are aware of some security problems in current PHP sources you
are as always welcome to report them and they will be fixed. I think
everybody here as always are thankful for any help we can get.
Ohh BTW. I am aware of many security problems in current PHP, actually
the whole world
is, because there are still a lot of "local" vulnerabilities unfixed
that were disclosed during
the MOPB. The ext/filter email issue is also not fixed in 5.2.2
And yes I know a bunch of bugs in PHP that were not disclosed during the
MOPB.
But what sense does it make to release them now, while a bunch of MOPB bugs
are not yet fixed or were marked as fixed in the release notes of 5.2.2
but were
not actually fixed.
Stefan
Ohh BTW. I am aware of many security problems in current PHP, actually
the whole world
is, because there are still a lot of "local" vulnerabilities unfixed
We seem to be in a disagreement about what security vulnerability is.
However, it is not very important since bugs are to be fixed anyway. I
am aware of one issue still unfixed - listed as #27 and #28. There are
also #1 and #2 which can not be fixed right now. Are there any other?
that were disclosed during
the MOPB. The ext/filter email issue is also not fixed in 5.2.2
I was talking about current code. Barring the possibility of time
travel, there's no way to fix anything in 5.2.2 now, so discussing it is
kinda pointless.
And yes I know a bunch of bugs in PHP that were not disclosed during the
MOPB.
And you do not report them because?
But what sense does it make to release them now, while a bunch of MOPB bugs
are not yet fixed or were marked as fixed in the release notes of 5.2.2
but were not actually fixed.
Those being?
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
If you are aware of some security problems in current PHP sources
you
are as always welcome to report them and they will be fixed. I think
everybody here as always are thankful for any help we can get.
Ohh BTW. I am aware of many security problems in current PHP, actually
the whole world
is, because there are still a lot of "local" vulnerabilities unfixed
that were disclosed during
the MOPB. The ext/filter email issue is also not fixed in 5.2.2And yes I know a bunch of bugs in PHP that were not disclosed during
the
MOPB.But what sense does it make to release them now, while a bunch of MOPB
bugs
are not yet fixed or were marked as fixed in the release notes of
5.2.2
but were
not actually fixed.
Because work is progressing on some, discussion about how best to
proceed is progressing on others, some have been fixed, even to your
satisfaction, I would guess...
They're not ALL going to get fixed exactly the way you think they
should be fixed -- that's just part of working with a team.
If you know of bugs, just send them in via security@
Or, as you're not happy with the outcome of that, post them as you see
fit.
Ranting about them without actually posting them is kinda silly,
though, really... :-)
The more you post them, the more get fixed. You'll never get them all,
and you'll never get them all to get fixed your way, but it's better
to get at least some of them fixed, no?
You could even bring up the not-fixed-right ones as repeats once in a
while in YOPB.
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
2007/5/18, Stanislav Malyshev stas@zend.com:
Sane hosters do not rely on general-purpose language to provide
security, they use OS and hardware designed for exactly that purpose. ;)
unfortunately hosters has to equilibrate security vs/usability for
their customers.. so disaloowing 100% access to outside world is
frecuently not possible.
The issue with this remote url include thingy is that is hard to find
a valid use case ..does anyone has a real one ? why it was
introduced in the first place..?? no, Im not talking about crippling
the language for security reasons as some may argue..my point is this
"feature" in the reality causes far more harm than good and it has
become one of the top ways to attack applications since it's
introduction..my intention is only to make people think if the hassle
of adding new ini directives (like allow_url_include) or functions is
worth. maybe with PHP6 this issue can be addressed from it's roots
instead of adding yet another workaround.
my $2.
The issue with this remote url include thingy is that is hard to find
a valid use case ..does anyone has a real one ? why it was
I believe there is.
introduced in the first place..?? no, Im not talking about crippling
As I already said, it was never introduced. What was introduced is
stream functionality in filesystem layer that allows remote access.
Since include uses filesystem layer that means include can do that too.
introduction..my intention is only to make people think if the hassle
of adding new ini directives (like allow_url_include) or functions is
worth. maybe with PHP6 this issue can be addressed from it's roots
instead of adding yet another workaround.
How do you propose to address that (taking into account what I said above)?
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
2007/5/18, Stanislav Malyshev stas@zend.com:
Sane hosters do not rely on general-purpose language to provide
security, they use OS and hardware designed for exactly that
purpose. ;)unfortunately hosters has to equilibrate security vs/usability for
their customers.. so disaloowing 100% access to outside world is
frecuently not possible.The issue with this remote url include thingy is that is hard to find
a valid use case ..does anyone has a real one ? why it was
introduced in the first place..?? no, Im not talking about crippling
the language for security reasons as some may argue..my point is this
"feature" in the reality causes far more harm than good and it has
become one of the top ways to attack applications since it's
introduction..my intention is only to make people think if the hassle
of adding new ini directives (like allow_url_include) or functions is
worth. maybe with PHP6 this issue can be addressed from it's roots
instead of adding yet another workaround.
The main problem, I think, is that you are looking at allow_url_fopen
as a "Feature" somebody added, rather than as a side-effect of having
the base common code of include and fopen both working through the
same low-level functions.
Remote URL 'include' mostly "works" because it basically just calls
the C-equivalent of eval(file_get_contents()) -- the guts of include
and the guts of the basic file-reading code are the same code...
So it's either:
A) Re-write include from scratch to not use the same basic
file-reading functions as the rest of PHP uses.
B) Hack a black-list approach to disallow include() to use "remote"
files.
Unfortunately, A) is a ton more work than B), even if everybody
recognizes that B) is not necessarily the "best" answer.
And, in fact, B) is now having some false-positive (false-negative?)
side-effects of disallowing things like 'phar' from working, even
though it should work.
This is not a trivial "change one line of code" fix.
It's endemic to include and stream functionality, and there are pros
and cons to the various solutions being batted around.
I suspect that there are valid uses of remote include, and have
posted a couple (admittedly somewhat lame ones) already. I'm suspect
people who actually USE the feature have more realistic needs... But
perhaps not.
Even if nobody in the world needs the feature, and could re-code
their application to not use it, there are a lot of scripts that use
it, some more wisely than others...
But it seems like people are so polarized on this topic, and their own
views are so ingrained, that nobody is even willing to recognize that
other positions are valid, so we have an endless parade of "only my
answer is correct" here.
That is not effective communication, nor useful discourse, imho.
[insert Monty Python argument skit here]
Of course, suggestions with actual PATCHES to "fix" the problem in
whatever way the poster sees fit, and a shoot-out of testing those for
vulnerabilities and usablity would be most welcome. :-)
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
Hello Greg,
I would first ask the following question:
Why should the user be prevented to include remote site code?
#1: hoster and users are equal
The hoster - as the "person" providing for the php infrastructure - is trying
to prevent the user (and his own system) - as his partner - from injected
code by malicous others.
#2 hoster distrusts the user
By unknown reasons, the hoster thinks that the user is limited in his
capabilities and therefore wants to prevent his system from the user.
Functions like fsockopen are adding useful features to php. Communication
between different systems can be useful. Therefore it should not be disabled,
if it cannot be abused easily by 3rd parties.
I would consider the possibility to inject malicous code by using a query
string, as beeing easily achieved.
In my opinion, your proposal does satisfy #1 not #2. I see no sense though in
declaring a local stream as remote. But that's only a question of naming.
Wietse Venema called it tainted, as far as I remember.
I do agree with your assumption that remote code is not malicous in general.
But it is susceptible for changes by 3rd parties. There it might be useful to
add a feature to sign remote code.
Best Regards,
Oliver
Am Freitag, 18. Mai 2007 17:51 schrieb Greg Beaver:
Hi,
I think I have a solution that would allow user streams in PHP 6 and
still satisfy paranoid hosters.First, let me clarify what I see as the assumed problem, so that if I
have missed something, you will correct my assumption:My assumption:
The point of allow_url_include/allow_url_fopen is to prevent stupid
remote execution vulnerabilities like:<?php
include $_GET['dumb'];
?>allow_url_(include|fopen) is not intended to prevent users from
accessing remote sites, as it is still possible throughfsockopen()and
other methods to access the outside world. A firewall is the only way
to truly prevent access to the outside world.Note that the stream wrapper file:// is a local stream wrapper. Remote
stream wrappers access the outside world such as http:// ftp:// and
gopher://The problem:
Because there is no way to be sure that a userspace stream is not
remote, all userspace streams are marked as remote and so
allow_url_(include|fopen) applies to them. As such, because
allow_url_(include|fopen) are disabled by default in PHP 6, this will
effectively kill userspace streams for anything but niche usage.The solution:
Add a new function: stream_wrapper_set_local()
This function would be used to mark a registered user stream wrapper as
being local, which would allow it to be used. It would not affect
internal stream wrappers.Why would this be any different? The point of the allow_* options is to
make it more difficult to write insecure code. This would still apply,
as a user would have to explicitly register a stream wrapper as being
local. This way, our example code:<?php
include $_GET['dumb'];
?>would still fail on all the wrappers it should fail on. The malicious
use of a userspace stream wrapper that is remote would still fail unless
the user explicitly marked it as local.Paranoid hosters could simply put stream_wrapper_set_local() into the
disable_functions option.Comments?
Greg
Oliver Block wrote:
Hello Greg,
I would first ask the following question:
Why should the user be prevented to include remote site code?
#1: hoster and users are equal
The hoster - as the "person" providing for the php infrastructure - is trying
to prevent the user (and his own system) - as his partner - from injected
code by malicous others.#2 hoster distrusts the user
By unknown reasons, the hoster thinks that the user is limited in his
capabilities and therefore wants to prevent his system from the user.Functions like fsockopen are adding useful features to php. Communication
between different systems can be useful. Therefore it should not be disabled,
if it cannot be abused easily by 3rd parties.
I would consider the possibility to inject malicous code by using a query
string, as beeing easily achieved.In my opinion, your proposal does satisfy #1 not #2. I see no sense though in
declaring a local stream as remote. But that's only a question of naming.
Wietse Venema called it tainted, as far as I remember.I do agree with your assumption that remote code is not malicous in general.
But it is susceptible for changes by 3rd parties. There it might be useful to
add a feature to sign remote code.
?? My assumption is not that remote code is not malicious. In fact,
anyone developing under this assumption is asking to be attacked. I
must have been unclear.
My assumption was that the goal of allow_url_include=0 is to prevent
unintentional inclusion of remote code, as this is a serious source of
security vulnerabilities.
The problem is that a URL is not inherently remote. file://blah.php is
for instance obviously a local file. What is really annoying is that
userspace streams are considered to be remote arbitrarily. Let's think
about this for a second: if a user is too inexperienced to know they
should never use include with arbitrary user input, what are the chances
they will even know it is possible to write a user stream wrapper to
simulate http:// or other remote protocols, let alone know how to do it?
Stanislav's suggestion of auto-disabling allow_url_fopen in a userspace
stream if allow_url_include=1 should prevent the last unintentional hole.
However, it would also be nice if a userspace stream could register
itself as being remote, as this would add another layer of security.
Streams such as http://pear.php.net/HTTP_WebDAV_Client could then tell
PHP not to use them if allow_url_include=0, removing another attack
vector possibility.
Greg
The solution:
Add a new function: stream_wrapper_set_local()
So, basically, your function would be similar to:
"I'm removing the safety from the gun with which I might shoot myself
in the foot."
:-) :-) :-)
Would it be applied on an individual stream only, or could we consider
allowing something not unlike:
stream_wrapper_set_local('phar://*');
as a sort of "glob" where only streams that fit the pattern are
white-listed.
phar://* is probably a bad example...
'phar:///usr/local/lib/php_libs/*'
would seem to me to be a pretty clear way to express that phar files
found in the local file system at that path are kosher, but nothing
else is being white-listed in this call.
This would, I think, provide a better balance between security and
usability.
I have no idea if what I suggest is reasonable to implement or not.
It just seems like it "should" be and would be more useful to
application developers than having to whitelist streams
individually...
In fact, I suspect that if you have to call this function on each
stream individually, the masses will end up doing something that boils
down to:
<?php
stream_wrapper_set_local($_GET['foo']);
include($_GET['foo']);
?>
because they'll wrap it up in 20 levels of function calls and OOP
obfuscation^H^H^H^H^H^H^H^H^H abstraction, and not realize they've
just blown away the safety barrier when they call:
stream_wrapper_set_local($stream);
down in the guts of their code.
YMMV
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?