Vulnerability in Servers Using PHP
UPDATE
In lieu of recent attacks targetting Movable Type powered blogs a security threat has been revealed with many web hosts, not Movable Type. Although many hosts do have CgiWrap/suEXEC installed, a simple PHP script can be written and run on any account on a server. That script will print a list of all Movable Type and WordPress installations including usernames and passwords to databases on the entire server. This is a security flaw with web hosts and not any blogging application and only affects virtual shared hosting accounts.
The first step to combatting this would be to install the PHP directive "open_basedir" - this restricts the files PHP can open. Webhosts should also be running Apache from a "chroot jail" - the latter method will involve changing server configurations and hosts may be reluctant but if left open, the results are very scary.
Unfortunately there is nothing that can be done from an end user's point of view. You will need to contact your web host and ask them to install the said items. I cannot give examples beyond the above highlighted software as this is only something that can be done from the host side. Many big hosting providers have already been notified of this problem prior to this post and a few have plugged the hole. Make sure that you scan you templates on a regular basis and take a frequent backup of your database. Also make sure that you have enabled all the security features talked about in a previous tutorial
3 Comments
Leave a comment
Subscribe to Movalog's Feed
Sebastian said:
on Oct 4, 2004 7:28 PM | Reply
The problem comes from the fact that under the typical apache virtual hosting setup, all virtual sites are run as the same user. So if your site is on the server as mine, I can write a PHP script that can read your files.
This is not even a PHP problem. All CGI environments, like Perl or python, will have the same problem. The only solution is to use something like CGIWrap or suexec.
So if your site is hosted under such a setup, don't store any sensitive information. Not even on a database requiring a separate password, since that password is probably in a config file somewhere on your server and that can be accessed.
One way of telling if your server is using cgiwrap/suexec or not is to look at the ownership of files created by cgi or php programs. Your blog index and entry pages are good examples.
If the files are owned by your user, then your server probably uses cgiwrap/suexec. If the files are owned by "apache" or "web" or "nobody" or some other generic user, then it's NOT using any cgi wrapper and you are vulnerable.
Christine said:
on Oct 4, 2004 11:42 PM | Reply
Actually, wouldn't it be more accurate to place the blame on users not setting file permissions correctly? Because in the incidence of the one client that I have had with an issue like this, he had his files set to 777, leaving them open to the world.
I think that rather than pointing at the hosting companies, you need to (also?) point at the users themselves, reminding them to set their files to the most secure permissions possible. Permissions set to 777 will leave them open.
Arvind Satyanarayan said:
on Oct 5, 2004 9:23 AM | Reply
In the case of MT, the only way (that I know of) this can be stopped is setting mt.cfg and mt-db-pass.cgi to permissions 600. As discussed in a previous tutorial, this causes problems because the dynamic templating feature of MT 3.11 is rendered useless. I do now think this is a "fix," I do not feel that we must sacrifice features for security.