+1. I think Greg's suggestion would be a very good solution, combined with the existing 'allow_url_fopen' feature to protect 1st level calls:
1. User stream wrappers are not an 'exotic' feature reserved to some exotic hackers as some seem to think. It is not because you never used them that it is an exotic and negligible feature. They are absolutely mandatory to implement Greg's PHAR or my PHK package manager because there are several PHP functions which only take a filename as argument. In order to use these functions, where you cannot send directly some string data, you have to call them through a stream wrapper which will send this data for you. A simple example: if I give you a $string, consider this as a file's content and run it the same as it would be if I include()d this data from a real file. There are only two solutions: use a stream wrapper or write the data to a temp file before reading it back. 2. If we force 1st level calls to set a special flag to authorize stream wrappers, we loose the whole interest of the stream layered architecture. In order to clarify this, why don't you suggest to replace the flag with a whole set of new functions dedicated to URLs: fopen_url(), fread_url(), fwrite_url(),... This would be essentially the same. The stream wrappers keep their interest only if their use stays *transparent*. It is so true that I would like¨PHP to transparently gateway filename globbing and chdir()/getcwd() to stream wrappers. They must be seen as gateways, not as specific 'not so useful' annoying features. Have a look at http://phk.tekwire.net for a real full scale example. 3. What do we want to restrict ? The 1st security level is provided by the 'allow_url_fopen' switch. Now, we just want the stream wrapper code not to be able to communicate with the network. It is not a question of URL anymore. From inside a stream wrapper, you must be allowed to access another stream wrapper. The only thing we want to forbid is any access to a small list of C critical network functions. 4. That's why I think Greg's idea is the right one. Trying to restrict access at the PHP level is, IMO, impossible. It is not a question of 90% vs 100% protection (which is a total nonsense), it is a question of knowing at which level you put your barrier. I think that the only reliable way to implement it is to protect every C function opening a network connection. And, as there are few such C socket() calls in the PHP code, it should be quite light to implement (for somebody familiar with this kind of things :), compared to a conceptually related solution like tainting. Francois Greg Beaver wrote: > This would mean a new zend API function (or macro) would need to be created > that E_ERRORs out > if include/require is being called, and it would need to be inserted in the > front of all ftp, > url, pecl/ssh2, pecl_http, pecl/gopher, fsockopen and whatever else uses the > so-called > "internet" that I've forgotten. Fortunately, the list is finite. In this > way, user stream > handlers could be trusted, as they would simply not work (uncatchable > E_ERROR) if any remote > access is attempted. The same is true of pecl stream wrappers. As I recall, > the last I > heard was Rasmus said on IRC "that actually might work" and then it was > forgotten by all > parties including me. :) > My idea would *not* protect against third-party extensions, but since these > are not > distributed with PHP and PHP has no control over them anyways, I doubt that > this will be a > real issue, as large hosting companies are unlikely to install anything > third-party except > perhaps Zend Optimizer. > If "include_url" is introduced, it could be a large headache for PHP_Archive > and will be a > large headache for pecl/phar. Perhaps I'm the only one with this issue, but > I think > achieving full no-way internet include is relatively simple without > introducing new keywords. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
