ID: 37874 Updated by: [EMAIL PROTECTED] Reported By: Harry dot Boeck at t-online dot de Status: Bogus Bug Type: Documentation problem Operating System: all PHP Version: Irrelevant New Comment:
There is already: http://php.net/security.filesystem http://php.net/security.variables So I really can't think about a possible improvement. Previous Comments: ------------------------------------------------------------------------ [2006-06-22 14:10:25] [EMAIL PROTECTED] What are you talking about when speaking about "bypassing any restriction" ? Quite every configuration directive is documented in the manual. Any capable host is able to read the doc, expressing pretty well what the role of allow_url_fopen is: http://php.net/manual/en/ini.php . Remember, allow_url_fopen is a completely secure feature unless _you_ screw it. Would you also like having a warning "including tainted client data in the argument is dangerous" in about each filesystem functions, like unlink() ? If I understand you correctly, you want to have a warning somewhere about the danger of using code like include $_GET['page']; ? This security hole is not only related to allow_url_fopen, requesting page.php?page=/path/to/secret_file is posible even with allow_url_fopen disabled. The documentation about allow_url_fopen is fine. But maybe a security paragraph like http://php.net/session#session.security would be useful. ------------------------------------------------------------------------ [2006-06-22 13:10:26] Harry dot Boeck at t-online dot de Well, no point in "http://php.net/ref.filesystem#ini.allow-url-fopen"; nor in "http://php.net/features.remote-files"; nor in the comment in the configuration file explains anything about bypassing any restriction, does it? Additionally, nobody firstly taking some existing project in use will look in the deepth of the PHP-documentation when he tries to setup his server to get that application running, does he? Additionally, how many people using tools like dreamwaver will be looking at php code at all, for the only use of using those tools is often to just avoid having to go into the deepths of programming? At least in my environment i precisely encountered just such a case yesterday. >From the structure and the automatically generated comments in the php and html code i can clearly see, that the coding person has possibly not even taken a single look at the html and php code. Maybe, the documentation is not meant for those peoples. But for those really coding php and configurating servers, i would find it nice if there were some usefull hint at precisly that point in the documentation, where this directive is described, about the side effects (circumvention of restrictions). For me, when i firstly did setup my home server, i did setup several security settings, including register_globals to off and a restrictive execution path. Everything according to the documentation available to that point. Explicitely with reading the documentation about all and every configuration directive including "allow_url_fopen", being "on" per default and not documented to any degree about side effects. I believed in being on the secure side. Then, yesterday, i had to begin to work on a foreign project, temporarily moved onto my believed to bo secure server. The project simply used some replacement for some "include". In the very same moment, my server would have been open to the wide wild world. If that "allow_url_fopen" had been documented sufficiently, it would never have been enabled on my server. To the last: _I_ didn't open the project to the WWW before i looked through the code and tested some intrusions. _I_ realized the problem, searched the internet and found those entries alredy two years old in the "c't" and in various forums. But how many hobby-webmasters will do so before they are affected? I think, the entry in the documentation would be 4...5 lines of a few words (example given above). So it is not very usefull to do such a prolonged discussion here about such a simple matter... ------------------------------------------------------------------------ [2006-06-22 07:16:20] [EMAIL PROTECTED] I fail to see where the documentation was not enough precise. If you read http://php.net/ref.filesystem#ini.allow-url-fopen or http://php.net/features.remote-files. It's clearly stated that this directive affects the possibility to use URL wrappers. Thus, every functions allowed to use such wrappers (or URL-aware) will be affected. Notice that the configuration directive "allow_url_include" exists since PHP 6, to adress this very "security problem". ------------------------------------------------------------------------ [2006-06-21 12:43:21] Harry dot Boeck at t-online dot de Description: ------------ allow_url_fopen is incompletely documented concerning effects on file handling: This option allows usage of arbitrary files NOT only for file function, but for every file handling including "include"/"require", circumventing "include_path" and "doc_root". This effectively enables the entire internet to execute whatever they want in the php space on this server. This is a huge security risk. This is, however, only effective, when some possibility to manipulate any of the mentioned file operations is already present in the php code (for example, an argument replacement as "include $somefile"). This in turn is commonly seen not only in open source projects but also for example in dreamwaver productions. I have found reports dating from 2004 on the internet, where the risk is completely documented - but not in the php documentation, where it should be. Reproduce code: --------------- not applying Expected result: ---------------- There should be a complete description of the vulnaribility at least either in the configuration file or in the documentation. Actual result: -------------- The documentation refers only to the "file system functions" in general resp. to the "fopen"-function particularly. Concerning "require", there is only a hint, that inclusion of files was not possible even with "allow_url_fopen" enabled in earlier versions of php. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=37874&edit=1
