| Harry dot Boeck at t-online dot de 2006-06-24, 8:03 am |
| ID: 37874
User updated by: Harry dot Boeck at t-online dot de
Reported By: Harry dot Boeck at t-online dot de
Status: Bogus
Bug Type: Documentation problem
Operating System: all
PHP Version: Irrelevant
New Comment:
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...
Previous Comments:
------------------------------------------------------------------------
[2006-06-22 07:16:20] colder@php.net
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
|