ID: 37874 Comment by: judas dot iscariote at gmail dot com Reported By: Harry dot Boeck at t-online dot de Status: Open Bug Type: Documentation problem Operating System: all PHP Version: Irrelevant Assigned To: colder New Comment:
your latest comment have nothing to do with allow_url_fopen..looks like that is a combination of a MOS bug with the GLOBALS overwrite issue detected by Steffan Esser some time ago.. adittionally buggy code like include $_GET['page'] can be exploited even with allow_url_fopen , to read local files, or arbitrary code execution tricking the php://input wrapper ( that do not obey allow_url_fopen at all) I think this last point,and the NULL byte attack should be mentioned in the security docs too.. Previous Comments: ------------------------------------------------------------------------ [2006-06-22 15:13:24] Harry dot Boeck at t-online dot de Well, when i look at the intrusion attempts on my server, for example (cut off from the log): req:"GET /index2.php?option=com_content&do_pdf=1&id=1index2.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=... req:"GET /index.php?option=com_content&do_pdf=1&id=1index2.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=... req:"GET /mambo/index2.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=... req:"GET /Mambo/index2.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=... req:"GET /news/index2.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=... req:"GET /home/index2.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=... req:"GET /cvs/index2.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=... req:"GET /index.php?option=com_content&do_pdf=1&id=1index.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=... req:"GET /mambo/index.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=... req:"GET /Mambo/index.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=... req:"GET /news/index.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=... req:"GET /home/index.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=... req:"GET /cvs/index.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=... then it seems that there are at least _a_few_ people out there not being able to read the "pretty well" documentation while being able to program wide spread public programs versus being able to setup servers. They are, of course, only extremely rare exceptions! OK, i have done all i could to help those guys. If it shouldn't be, then i will let it be. ------------------------------------------------------------------------ [2006-06-22 14:56:15] [EMAIL PROTECTED] It seems that this manual page[1] needs some fixes and is not really up to date. I'll also add something about the "include security hole". [1] http://php.net/security.filesystem ------------------------------------------------------------------------ [2006-06-22 14:15:12] [EMAIL PROTECTED] There is already: http://php.net/security.filesystem http://php.net/security.variables So I really can't think about a possible improvement. ------------------------------------------------------------------------ [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... ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/37874 -- Edit this bug report at http://bugs.php.net/?id=37874&edit=1
