security problem: how can I restrict path of require() command

sfullman

I have a pretty garden-variety linux server. I have some websites for customers set up on it. Each website is a user in linux, cpm001, cpm002, cpm003, etc. (my company is Compass Point Media). Each website is found in the /home directory under their username:

/home/cpm001/public_html/.
/home/cpm002/public_html/.

and I have php running on the server.

HERE IS THE PROBLEM:

There is nothing from stopping cpm001 from using require() like this to get another user's sensitive information:

//this could be called by cpm001:
require('/home/cpm002/public_html/config.php');
//they now have access to the vars in that file:
echo "Aha!  cpm002's password is $MASTER_PASSWORD !";

All of the files in cpm001 folder belong to cpm001 (or sometimes root but I manage those). seems there is a directive in php.ini that restricts the require() function to ony allow files inside the root folder of the owner of the file. Am I correct on this? Otherwise I see a huge security hole. Please help, and thanks in advance!!!!

Samuel Fullman

hurricane

I found an article from this website
http://www.phpadvisory.com/articles/view.phtml?ID=5
that might be some help.

"Trusting Environment Variables
When you type "ls" at the UNIX prompt, the shell goes through a list of directories looking for a program called "ls". As soon as it finds it in some location, like /bin, for example, the shell executes the program and waits patiently for it to return. The list of directories in which the shell looks for the program is specified in an environment variable, usually $PATH. Similarly, when you include() or require() a file from a PHP script, the system will search for it in a specified list of directories; the environment variable $LD_LIBRARY_PATH specifies a path for dynamically loaded libraries, etc.

The script does not have control over the content of environment variables at the moment it starts executing. An adversary can modify the path to point to a Trojan version of the program that is being called or the file that is being included. This is an easy way for attackers to get hostile code running on the system.

Some sites restrict access to content based on the link from which the user arrived. They use the $HTTP_REFERER variable to determine this. But since the information comes from the browser, there is nothing to stop the user from assigning it an arbitrary value. Such forms of "authentication" are very unreliable.

Even if the information does not come from the user, environment variables still cannot be trusted. On most Unix systems, the environment variables are stored at the bottom of the system stack. Now, PHP does its own automatic dynamic memory management, so there isn't really a risk of buffer overflows in PHP scripts. But an attacker can still exploit some other piece of software that is running on the server to gain access to the stack. Because of the way the stack is structured, they can now overwrite the values of environment variables. Consequently, the PHP script that blindly relies on those variables is no longer secure.

From a security perspective, environment variables and user input data really aren't very different. They all represent data of unknown origin that may be hostile. Therefore, their use should be minimized whenever possible and their content examined and filtered the rest of the time. A good practice is to redefine all environment variables that will be used in the script before actually using them. This is not always possible, but does help offer a somewhat higher degree of confidence in their content."

MarkR

You need to:

Set open_basedir on each virtual host to only allow them to open files within their own web area. This will prevent require() being used in the way described above.
Use disable_function (in php.ini) to disable all functions which could be used to circumvent this restriction, such as system, and popen, shell_exec etc.

This will probably be effective, but I can't guarantee that there are no other ways to circumvent the protection, because some PHP features may use filesystem access methods which don't obey the above checks.

Of course if they can use SSI, CGI etc, restricting PHP makes no security difference.

Mark