Re: Comments on PHP security

Greg, i was not talking about providing all the different versions of include. For me it is a broken application design to include anything out of an URL wrapper. However it would also be fine to just have allow_url_include affect all URLs and to be setable by ini_set() and be turned off by default. Insane applications can then turn it on/off for every REMOTE URL they need. Aside from that there could be a setting for the admin to completely disallow URLs marked as is_URL. Stefan Esser

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

The problem is, for user streams you can't be sure they are truly local - user stream can do anything, including accessing any URLs, without the streams layer having any say in that. They only way to ensure that user stream is local is for the stream wrapper author to write it local, which we can't control.

Hi, First of all I admit I'm no PHP security expert or PHP internals expert or anything, so please don't flame me if I say something stupid. Wouldn't simply adding a flag to allow url's (which includes all '*://' streams), in functions that opens streams be enough? For example: fopen($file, 'r') and fopen($url, 'ru') and fopen('php://output', 'ru'). To my opinion, using '*://' streams is an advanced feature. Developers who are using that, should be able to make sure no urls are opened. Again, just an idea. Last, I'm a software developer at a shared hosting company. To my opinion, making sure that users don't touch other people's files, does not belong in the PHP layer. With other apache modules you can do nasty thing as well. We (not me) have written a kernel patch to allow switching of the current processes (much like sudo) and a matching apache module. Since the privileges only allow the user or group to access the file, linux does the rest. An other solution is to start PHP as cgi under the correct user, but other things will never be really save. Best regards, Arnold Greg Beaver wrote: