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 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
