ID: 28932
Updated by: iliaa@php.net
Reported By: php at ter dot dk
-Status: Assigned
+Status: Bogus
Bug Type: Safe Mode/open_basedir
Operating System: *
PHP Version: 4CVS, 5CVS (2005-02-03)
Assigned To: iliaa
New Comment:
It is not practical to test every single file returned by glob()
against safe_mode & open_basedir, it would terribly slow to check every
single file/directory.
As far as the error message goes, everytime you hit open_basedir limit
the error indicating that path XYZ could not be opened due to
open_basedir/safe_mode restriction.
Previous Comments:
------------------------------------------------------------------------
[2005-02-06 06:55:54] sniper@php.net
Ilia, check this out.
------------------------------------------------------------------------
[2005-02-03 05:49:14] php at ter dot dk
Sorry - still no luck with that CVS snapshot (4.3.11).
glob() still just check the first file. Example:
$ php4-STABLE-200502030330/sapi/cli/php -d safe_mode=On -r
'print_r(glob("/tmp/*"));'
Warning: glob(): SAFE MODE Restriction in effect. The script whose uid
is 1000 is not allowed to access /tmp/build owned by uid 33 in Command
line code on line 1
$ touch /tmp/a
$ php4-STABLE-200502030330/sapi/cli/php -d safe_mode=On -r
'print_r(glob("/tmp/*"));'
Array
(
[0] => /tmp/a
[1] => /tmp/build
[2] => /tmp/config
[3] => /tmp/lib
[4] => /tmp/magic5su99j
[5] => /tmp/mailgraph
[6] => /tmp/out.txt
[7] => /tmp/phptest_sess_03735f0f339412345678901234567890
[8] => /tmp/phptest_sess_0e838e6ff9e312345678901234567890
(.. and so on ..)
1) appearently doesn't seem to be fixed. Please don't comment on the
fact that if I have shell access, I have access to those file names
anyway - this was just a quick test :)
As the example above shows, 2b) isn't fixed either. The error (".. is
not allowed to access /tmp/build owned by .."). An error due to
open_basedir-restriction discloses it as well: "open_basedir
restriction in effect. File(/tmp/build) is not within the allowed
path(s): .."
So, it still seem that even under open_basedir- and
safe_mode-restriction, the issue is still present.
.. and just to clarify: I do agree that safe_mode is not per se safe,
and all these vulnerabilities would be present if a user had access to
a shell or other languages - but there's no need for further
inconsistency.
I'll e-mail a simple proof-of-concept-code of filepath-walking
security@ and sniper@. The code utilizes these warning messages. The
code is pretty simple (not to mention ugly), though.
- Peter Brodersen
------------------------------------------------------------------------
[2005-02-03 05:03:17] sniper@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
------------------------------------------------------------------------
[2004-07-27 03:54:14] php at ter dot dk
I have now performed some tests with open_basedir as you suggested.
Two of the issues (2a: empty glob-match is not restricted, and 2b:
filenames is disclosed in warning) is also present under open_basedir.
Proof of concept:
http://basedir.ter.dk/notexist.php (2a)
http://basedir.ter.dk/nobody.php (2b)
As mentioned in http://news.php.net/php.internals/11578 , even:
- with safe_mode-restriction
- with open_basedir-restriction
- with custom session.save_path for each virtual host/user
- without allowing php-scripts of the same UID as the Apache user to be
executed (mostly because of the possibility of bypassing a
safe_mode-UID-check)
.. a user can still walk around and get info on directory and file
names fairly easy, e.g. finding session files, giving a
hijack-opportunity.
In other words: open_basedir will not help us from preventing glob() to
be maliciously used to get information about directory and file names.
This is why I have re-opened the bug: two of the issues is still
present under open_basedir-restriction (although the Summary could be
changed to reflect this).
As a side note, not related to the above reasons for re-opening the
bug:
The retrieval of a file list is usually connected to the permissions
for the directory (e.g. the read-bit for a directory in unix).
Following this logic, the same restriction should be added here. At
least that's the case for opendir().
There are no differences between glob() and opendir(), since the
directory handle from opendir() is only usable by readdir(), that
returns a filename from the directory.
Both functions is used to retrieve filenames from a directory, no more,
no less. Same effect, different approaches.
Futhermore, the first-file-check is still useless, as a similar check
isn't performed on readdir(). If we perform opendir() on our own
directory, the ownership of the files in the directory has no effect on
readdir() - there is no restriction by safe_mode in this case. I could
put up a test case for this too, although it is pretty easy to test
out.
If there are any more suggestions for restrictions I could test
(besides safe_mode, open_basedir, etc.), please let me know :)
Thanks for your patience.
- Peter Brodersen
------------------------------------------------------------------------
[2004-06-29 17:45:01] iliaa@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to
report
a bug at http://bugs.php.net/how-to-report.php
safe_mode is not entirely safe and has many drawbacks. It
is much better to use open_basedir to restrict the user to
their home directory or any other set of directories.
As far as glob() goes the check is done on the 1st file,
since ultimately you get data about the files inside the
directory and not the directory itself. More over glob
directory may infact be a pattern and not an actual
directory, making the check based on that nearly
impossible.
------------------------------------------------------------------------
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/28932
--
Edit this bug report at http://bugs.php.net/?id=28932&edit=1