Preventing file access via PHP in a shared hosting environment 1

[jimoblak]

I just discovered that one of my hosting providers has a bad configuration of PHP/Apache. Using PHP, I am able to navigate to other users' directories in the shared hosting environment. I can even access the root file system. While I can read/view most all files and folders, I can only modify those with 0777 permissions via PHP. I'm not sure what user PHP is running as. The server API is via Apache and not CGI.

The server is running:
Apache/1.3.33 (Debian GNU/Linux) Sun-ONE-ASP/4.0.0 PHP/4.3.10-18 mod_ssl/2.8.22 OpenSSL/0.9.7e FrontPage/5.0.2.2635

The PHP script that I am using to navigate the server does not work on any other web host that I use. I cannot even get the script to navigate my own default Ubuntu 6.10 system running the current versions of Apache/PHP. The buggy web host is telling me that they need about a month to correct and secure this server. I'm not buying it. Isn't there some basic setting in php.ini that would restrict PHP script access to the users' home directories? Is this just a matter of updating PHP to a version within the past two years? What's the best way to secure this?

 

[jpadie]

it's not really a php problem. the host should fix the problem at the ACL level.

you should name and shame the host so that others don't get caught by this. I know that one of my hosts (1 and1) has some strange permission issues but nothing as bad as what you describe.

you can create a solution for php through the use of safemode but this does not prevent a user circumventing the protection through use of other languages like perl.

 

[jpadie]

actually safe_mode is not a great idea either as it is being removed from php6. open_basedir() configuration restraints will still exist and will prevent users from using php to navigate to other user's directories. but, again, this does not solve the issue for other languages and, as the php manual points out, there is a deeper architectural issue that the hosts need to solve.

of course, running php in cgi mode solves these problems (although exposes other issues).

 

[jimoblak]

I'm studying up on access control lists now. Thanks.

I considered 1and1. What kind of weird permission issues do they have? I also use powweb.com which runs PHP via CGI. What issues are exposed via CGI other than what I see here?

I've been holding off on the name/shame tactic. Of course with full access, I was able to obtain their client list with email addresses. I saw the hosting provider's intranet directory which included sales plans, security plans, and photos from a conference room whiteboard in their 'secure hosting center that uses pass cards for all employees'. --sigh--

 

[jpadie]

i think that's the only major downside (if one of the circumstances apply). there is also the persistency of the connection between apache and the cgi. in a classic set up there is latency due to apache needing to instantiate a separate link to the cgi for each page impression. Fast CGI avoids this problem, I believe.