Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » potential solution to user streams + allow_url_include=off »

potential solution to user streams + allow_url_include=off

php.internals

Greg Beaver

19 years ago
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

Ilia A.

19 years ago
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. On 18-May-07, at 11:51 AM, Greg Beaver wrote:
> 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
Ilia Alshanetsky

LAUPRETRE François (P)

19 years ago
> From: Ilia Alshanetsky [mailto:ilia@prohost.org]
> 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.
If I understand well, the goal here is not to mark remote stream wrappers as local and, thus, bypass remote protection. The goal is to be able to mark intrinsically-local stream wrappers as local. The primary clients for this feature are PHP_Archive & PHK. Both don't have anything to do with remote access, but there is no way to implement them without a stream wrapper. It is not a question of bypassing filters as the default behavior remains the same. It is just the possibility to control the filter from a secure place (if we don't consider the code to be secure, we can restart the whole discussion). The important point in Greg's proposal is that it does not allow to mark an internal remote stream as local. Regards Francois

Stanislav Malyshev

19 years ago
> If I understand well, the goal here is not to mark remote stream > wrappers as local and, thus, bypass remote protection. The goal is to > be able to mark intrinsically-local stream wrappers as local. The
How'd you achieve the distinction? If you define the stream, don't you want to make it work? If you want to make it work, you have to declare it local.
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/

LAUPRETRE François (P)

19 years ago
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

Stanislav Malyshev

19 years ago
> 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/

Rasmus Lerdorf

19 years ago
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 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?
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

Stanislav Malyshev

19 years ago
I think the problem could be solved this way: 0. 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). 1. By default, allow_remote_inclue=0, allow_remote_fopen=1 2. Stream can be of three types - remote, local and user/local. 3. User streams can be declared when registered as either remote or user/local, remote being the default. 4. 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: 1. Adding optional parameter to stream registration functions. 2. 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/

Stanislav Malyshev

19 years ago
oh, and I forgot another thing: 5. 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: > 0. 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). > 1. By default, allow_remote_inclue=0, allow_remote_fopen=1 > 2. Stream can be of three types - remote, local and user/local. > 3. User streams can be declared when registered as either remote or > user/local, remote being the default. > 4. 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/

Greg Beaver

19 years ago
Stanislav Malyshev wrote:
> oh, and I forgot another thing: > > 5. 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: >> 0. 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). >> 1. By default, allow_remote_inclue=0, allow_remote_fopen=1 >> 2. Stream can be of three types - remote, local and user/local. >> 3. User streams can be declared when registered as either remote or >> user/local, remote being the default. >> 4. 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

Stanislav Malyshev

19 years ago
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: >>> 0. 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). >>> 1. By default, allow_remote_inclue=0, allow_remote_fopen=1 >>> 2. Stream can be of three types - remote, local and user/local. >>> 3. User streams can be declared when registered as either remote or >>> user/local, remote being the default. >>> 4. 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

19 years ago
> 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/

Marcus Börger

19 years ago
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: >>>> 0. 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). >>>> 1. By default, allow_remote_inclue=0, allow_remote_fopen=1 >>>> 2. Stream can be of three types - remote, local and user/local. >>>> 3. User streams can be declared when registered as either remote or >>>> user/local, remote being the default. >>>> 4. When operation on user/local stream is run, allow_remote_fopen is >>>> disabled if allow_remote_include was disabled.
Best regards, Marcus

Stanislav Malyshev

19 years ago
> 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/

LAUPRETRE François (P)

19 years ago
> From: Stanislav Malyshev [mailto:stas@zend.com] > > According to the plan below, attached is the patch that > restricts user > streams from executing dangerous operations inside include context. > Please comment.
I see that you added a boolean arg to stream_wrapper_register(). Why couldn't it be an integer mask of OR-ed predefined constants, providing some space for more stream options. A local stream would be created with : stream_wrapper_register($protocol,$class,STREAM_IS_LOCAL); Best regards Francois

Stanislav Malyshev

19 years ago
> I see that you added a boolean arg to stream_wrapper_register(). Why > couldn't it be an integer mask of OR-ed predefined constants, providing > some space for more stream options. A local stream would be created with : > > stream_wrapper_register($protocol,$class,STREAM_IS_LOCAL);
Well, it could be if people see the use for it.
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/

Stanislav Malyshev

19 years ago
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: >>>> 1. By default, allow_remote_inclue=0, allow_remote_fopen=1 >>>> 2. Stream can be of three types - remote, local and user/local. >>>> 3. User streams can be declared when registered as either remote or >>>> user/local, remote being the default. >>>> 4. 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/

Cristian Rodriguez

19 years ago
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 ;) )

Stanislav Malyshev

19 years ago
> 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/

Edin Kadribasic

19 years ago
On 19/05/2007, at 1.47, Cristian Rodriguez wrote:
> 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

Richard Lynch

19 years ago
On Fri, May 18, 2007 6:47 pm, Cristian Rodriguez wrote:
> 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?

Cristian Rodriguez

19 years ago
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..

Stanislav Malyshev

19 years ago
>> 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/

Stefan Esser

19 years ago
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

Stanislav Malyshev

19 years ago
> 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/

Stefan Esser

19 years ago
> 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

Stanislav Malyshev

19 years ago
> 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/

Stefan Esser

19 years ago
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

Stanislav Malyshev

19 years ago
> 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/

Stefan Esser

19 years ago
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

Kevin Waterson

19 years ago
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."

Stefan Esser

19 years ago
> 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

Stefan Esser

19 years ago
> 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

Stanislav Malyshev

19 years ago
> 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/

Richard Lynch

19 years ago
On Sat, May 19, 2007 3:00 am, Stefan Esser wrote:
> >> 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.
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?

Cristian Rodriguez

19 years ago
>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.

Stanislav Malyshev

19 years ago
> 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/

Richard Lynch

19 years ago
On Sat, May 19, 2007 4:42 am, Cristian Rodriguez wrote:
>>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?

Oliver Block

19 years ago
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:

Greg Beaver

19 years ago
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

Richard Lynch

19 years ago
On Fri, May 18, 2007 10:51 am, Greg Beaver wrote:
> 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?