Re: Security concerns with Virtual Hosts

This is what safe_mode addresses. On Tue, 13 Nov 2001, Michael A. Peters wrote: > I am not going to mention which host I'm using for obvious reasons. > > However, I'm wondering if it is just a mis-configuration, or if it is a > weakness in php. > > With this host, you initially have the same database password to the MySQL > database as you do to the account. It is wise to change both, and to > change them to different passwords, but this is the real world, baby... > > Anyway, when setting up phpbb I didn't like the fact that the password is > stored within the document root. That's easy enough to change- move it > outside, and run a sed script to change the include path for that file. > > I then thought of another issue. My MySQL database name that was given to > me is identical to my username to log into this server. So I did a SHOW > DATABASES in MySQL and got myself a collection of all the user names on > the system. > > Then I wrote a script to wget > http://servername/~username/phpbb/config.php > What it got wasn't useful, but did tell me the file was there. > > So I wrote a php script in my directory to sizeof > /home/username/public_html/phpbb/config.php and then send the text/plain > mime type, and read the file. > > Right there in my browser I had the a text file containing some guys MySQL > password, which could be his login password as well. > > There were about a dozen sites running phpbb in a directory called phpbb > with the config file where I expected it to be. > > The web server MUST have permission to read that file since php is an > apache module. > > What I would like to know is if there an apache directive you can put in a > VirtualHost container that tells the php engine that it is NOT allowed to > read files or include files or etc. outside of a certain directory. > > A directive that could look like this: > phpreadroot "/home/username" > > There's still the problem of the exec() function, which could circumvent > that, but exec() I think can be turned off (and probably should on > multiuser systems) > > As a user, if I tried to cat the file, I would be rejected. But the web > server would not be. I assume this same type of vulnerability exists with > cgi-bin as well, although I think there are solutions where the script > runs with the users permissions, not the web servers's. I don't know > cgi-bin security that well. > > I guess the bottom line is be sure to have your database password > different from your login password, and rename and/or move any config > files that contain the database password, but is there any way within php > to limit the ability of people to do what I did? > > There's a bazillion user accounts on this machine, most of them porn > sites, and lets just say I don't personally believe that "porn webmasters" > will follow the common courtesy rules. > > Hell, I guess even I didn't technically- since I did extract someone's > database password. > > Any ideas? >