ID: 28932 User updated by: php at ter dot dk Reported By: php at ter dot dk -Status: Bogus +Status: Open Bug Type: Directory function related Operating System: Linux -PHP Version: 4.3.7 +PHP Version: 4.3.8 New Comment:
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 Previous Comments: ------------------------------------------------------------------------ [2004-06-29 17:45:01] [EMAIL PROTECTED] 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. ------------------------------------------------------------------------ [2004-06-29 01:47:57] php at ter dot dk I'm baffled... I really am! First of all, I propose a change to *one* UID-check on the directory alone (currently there are *two' checks, whether UID matches on the directory || the UID matches on the first file). I'm not voting for a UID check for every single file and I haven't mentioned that as a solution, so please don't use that argument. Furthermore, currently safe_mode-users would be able to access every single session file. Not only the one they created themselves (as mentioned in bug #28242 ), but each and every single session stored on the server! Please answer: What is the rationale for just checking the first file? There isn't any. It will lead to random, unpredicted results and confusion. Safemode has prevented users of accessing any information that they aren't permitted to. It doesn't make sense deciding globally that "It wouldn't harm for users to know of files at another host". There is no reason for providing users in safe mode with this information in the first place. What I really would like to see is: 1. Rationale for this random-check at first file. This is slower than just checking the dir alone, so please no "This is too slow"-argument. At least remove this check, as it doesn't make any sense. 2. Rationale for not updating the documentation regarding file and session security. There is no mention at all for using custom save_paths. If this bug really is "bogus", at least change it to a documentation issue, instead of hiding important information for the users. The same problem was mentioned in bug #28242 - the documentation really is pretty poor on this issue! 3. In summary, as of marking this bug as bogus, please state clearly: "Yes, a user should be able to see every session file in safe_mode" and "Yes, a user should be able to figure out every filename on the system requiring a small amount of work as opposed to brute force". As mentioned, I'm baffled. Sincerely, Peter Brodersen ------------------------------------------------------------------------ [2004-06-28 22:04:52] [EMAIL PROTECTED] 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 Checking each file inside a directory would be too slow, same thing goes for opendir() & readdir(). Given that you just get a file list and no other information or the ability to access those file. In this particular case there is no loss of security. ------------------------------------------------------------------------ [2004-06-28 11:37:01] php at ter dot dk (re-changed summary) ------------------------------------------------------------------------ [2004-06-28 05:36:39] php at ter dot dk As a sidenote related to session security this bug could in a default setup with multiple virtual hosts in safe mode (as in a typical webhosting-setup) be exploited pretty bad by a single customer, retrieving ALL current sessionids: 1. Create a folder which is world-writable 2. Create a PHP-script that writes to a new .php-file in that folder (making that file having the same user as the Apache user), using something like glob(ini_get("session.save_path")."/sess_*") 3. Access that PHP-script via a browser. Since the script is owned by the same UID as the Apache-user and the session-files, and glob() checks the UID for the first file (where it instead only should check the UID for the directory), a full list of *all* session files is available - even sessions for sites under other virtual hosts. Combined with the possible exploit mentioned in bug #28242 (online test at http://stock.ter.dk/session.php - the bug was dismissed as "not our problem; every single administrator in the world would just have to create a custom save_path for each and every virtual host"), the user could read and write sesssion data to every single session on the server. The Filesystem and Security chapter still doesn't mention anything about the problem, and even the Safe Mode chapter states: " The PHP safe mode is an attempt to solve the shared-server security problem. It is architecturally incorrect to try to solve this problem at the PHP level, but since the alternatives at the web server and OS levels aren't very realistic, many people, especially ISP's, use safe mode for now." I agree that it would be nice if every single administrator would have separate session.save_path for each virtual host or even jailed every user, but as mentioned above, it isn't that realistic. I really hope that one would consider reworking the session storage process as mentioned in bug #28242, and somewhat creating a harder job to find or accessing session files Some approaches to solve parts of the problem could be adding the UID to the session file in safe mode (as HTTP authentication currently is doing), the servername, a hash of both, and/or by other means not having users to be able to access the session files directly (which even could mean not allowing scripts - still in safe mode - with the same UID as the Apache user, although some applications might depend on this functionality with serverside-generated php-code) or otherwise disallow file related functions from accessing sess_*-files at all - once again, still only in safe mode. .. and even if my session-related concern is disregarded, I still hope the glob()-bug is fixed :) - Peter Brodersen ------------------------------------------------------------------------ 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
