# potential solution to user streams + allow_url_include=off - Thread: https://externals.io/message/29517 - Original archive: https://news-web.php.net/php.internals/29517 - Started by Greg Beaver on 2007-05-18T15:51:40+00:00 - Messages: 43 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/29517.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #29517 — Greg Beaver — 2007-05-18T15:51:40+00:00 URL: https://externals.io/message/29517#29517 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: 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: 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 --- ## #29518 — Ilia Alshanetsky — 2007-05-18T15:57:02+00:00 URL: https://externals.io/message/29517#29518 · In reply to: #29517 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: > > 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: > > 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 --- ## #29520 — francois.laupretre@ratp.fr — 2007-05-18T17:21:41+00:00 URL: https://externals.io/message/29517#29520 · In reply to: #29517 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 --- ## #29522 — Stanislav Malyshev — 2007-05-18T17:58:38+00:00 URL: https://externals.io/message/29517#29522 · In reply to: #29517 > 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/ --- ## #29524 — Stanislav Malyshev — 2007-05-18T18:23:31+00:00 URL: https://externals.io/message/29517#29524 · In reply to: #29517 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/ --- ## #29525 — Stanislav Malyshev — 2007-05-18T18:32:25+00:00 URL: https://externals.io/message/29517#29525 · In reply to: #29524 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/ --- ## #29527 — Greg Beaver — 2007-05-18T21:29:12+00:00 URL: https://externals.io/message/29517#29527 · In reply to: #29525 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. > > > […] This is cleaner than my suggestion, I like it. It would also be very easy to implement. Greg --- ## #29529 — Cristian Rodriguez — 2007-05-18T23:47:05+00:00 URL: https://externals.io/message/29517#29529 · In reply to: #29517 2007/5/18, Greg Beaver : > 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 ;) ) --- ## #29530 — Cristian Rodriguez — 2007-05-19T01:13:47+00:00 URL: https://externals.io/message/29517#29530 · In reply to: #29517 2007/5/18, Greg Beaver : > 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.. --- ## #29531 — Stanislav Malyshev — 2007-05-19T01:52:22+00:00 URL: https://externals.io/message/29517#29531 · In reply to: #29530 > > […] > > 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/ --- ## #29532 — Stanislav Malyshev — 2007-05-19T01:54:09+00:00 URL: https://externals.io/message/29517#29532 · In reply to: #29529 > 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/ --- ## #29534 — Stefan Esser — 2007-05-19T07:08:55+00:00 URL: https://externals.io/message/29517#29534 · In reply to: #29531 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 --- ## #29535 — Rasmus Lerdorf — 2007-05-19T07:11:58+00:00 URL: https://externals.io/message/29517#29535 · In reply to: #29522 Stanislav Malyshev wrote: > > […] > > 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 --- ## #29536 — Stanislav Malyshev — 2007-05-19T07:32:38+00:00 URL: https://externals.io/message/29517#29536 · In reply to: #29534 > 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/ --- ## #29537 — Stefan Esser — 2007-05-19T07:47:36+00:00 URL: https://externals.io/message/29517#29537 · In reply to: #29536 > 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 --- ## #29538 — Stanislav Malyshev — 2007-05-19T07:57:45+00:00 URL: https://externals.io/message/29517#29538 · In reply to: #29537 > 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/ --- ## #29540 — Stefan Esser — 2007-05-19T08:00:52+00:00 URL: https://externals.io/message/29517#29540 · In reply to: #29536 > 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 --- ## #29541 — Stefan Esser — 2007-05-19T08:16:32+00:00 URL: https://externals.io/message/29517#29541 · In reply to: #29538 Stanislav Malyshev schrieb: > > […] > > 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 --- ## #29542 — Stanislav Malyshev — 2007-05-19T08:20:46+00:00 URL: https://externals.io/message/29517#29542 · In reply to: #29540 > 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/ --- ## #29543 — Edin Kadribasic — 2007-05-19T08:22:49+00:00 URL: https://externals.io/message/29517#29543 · In reply to: #29529 > 2007/5/18, Greg Beaver : > > > […] > > 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 --- ## #29544 — Stanislav Malyshev — 2007-05-19T08:29:18+00:00 URL: https://externals.io/message/29517#29544 · In reply to: #29541 > 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/ --- ## #29545 — Stefan Esser — 2007-05-19T09:00:22+00:00 URL: https://externals.io/message/29517#29545 · In reply to: #29544 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 --- ## #29547 — Cristian Rodriguez — 2007-05-19T09:42:39+00:00 URL: https://externals.io/message/29517#29547 · In reply to: #29531 >2007/5/18, Stanislav Malyshev : > 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. --- ## #29550 — Oliver Block — 2007-05-19T10:34:03+00:00 URL: https://externals.io/message/29517#29550 · In reply to: #29517 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: > > 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: > > 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 --- ## #29561 — Greg Beaver — 2007-05-19T15:08:27+00:00 URL: https://externals.io/message/29517#29561 · In reply to: #29550 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 --- Next page: https://externals.io/message/29517.md?page=2