New PHP Exploit
Posted by jon-f, 09-11-2007, 06:27 PM check this out http://seclists.org/bugtraq/2007/Sep/0105.html That could do some damage, all someone would have to do is get shell on a site or be able to see config.php and then connect with that database and mass deface the server or put shells on other sites. Anyone know of any way to prevent this?
Posted by Patrick, 09-11-2007, 06:49 PM Have you tested the exploit? It doesn't work with my setup, even with the hex removed and replaced with standard text.
Posted by Tom P, 09-11-2007, 07:23 PM I have checked this on our servers and it does not work, I have tried different variations of file names (hexed and plain text), different accounts and such. I have then checked the MySQL permissions and I can't speak for all cPanel setups but I can for ours. The way MySQL permissions are assigned is full privileges on the tables for the account, but no privileges higher up. Since Data -> File access is a permission that can't be assigned per table (only in the root of the account) it does not affect our cPanel setup, and I think it's very likely that it does not effect any other cPanel setup. In any case, this is not a PHP vuln but a MySQL one, and only if the MySQL account is setup with loose permissions. Please correct me if I am wrong on this in any way.
Posted by bin_asc, 09-11-2007, 07:43 PM Even so, I`d like to find out if it`s reproduceable at least ... Last edited by bin_asc; 09-11-2007 at 07:50 PM.
Posted by Patrick, 09-11-2007, 07:45 PM The exploit wouldn't be OS independent... if it doesn't work under FreeBSD or CentOS, I can't see how it has a chance to work under Debian. To those who did try it, what OS and PHP5 version were you using?
Posted by Tom P, 09-11-2007, 07:49 PM PHP 5.2.1 but as I said in my previous post it's much more to do with the MySQL config, if you have access to perl it would work exactly the same. The problem is MySQL permissions to include file data (MySQL doesn't have a basedir directive )
Posted by Patrick, 09-11-2007, 07:54 PM You are correct Thecks, the exploit does work if you give it file (global) privileges... something cPanel does not do by default.
Posted by bin_asc, 09-11-2007, 07:56 PM Safe for now.
Posted by RBBOT, 09-13-2007, 07:38 AM I woudln't even classify that as an exploit - just an example of how not to configure your mysql server. It boils down to "If you give someone permission to write anywhere on the disk in mysql, then they can write anywhere on the disk in mysql" Mysql does have an equivilent of basedir: --secure-file-priv=path
Posted by Tom P, 09-13-2007, 07:44 AM RBBOT, You are right that it isn't an exploit just a bad configuration. Correct me if I'm wrong but isn't secure-file-priv a command line switch? If it is, then you could only limit users say, within the /home directory but then they could still read other users files.
Posted by RBBOT, 09-13-2007, 08:40 AM Yes, it is a command line switch or config file option. It can't be applied to individual users only to the server as a whole. However, if you have a server where you do need to give the file privilege (e.g. a single user system) it is worth applying this switch to tighten security. If you have a shared server, switching file access off is the correct configuration.
Posted by Tom P, 09-13-2007, 08:47 AM Agreed! Case closed. (always wanted to say that )
Posted by Annex, 09-13-2007, 08:49 AM You really should worry about this one http://www.milw0rm.com/exploits/4392
Posted by Tom P, 09-13-2007, 09:29 AM Yes, that one is a little more problematic. However as long as you have open_basedir option enabled then this won't affect you. If you don't, then I suggest you should start using it especially if you are hosting a shared enviroment! If you only have safe mode enabled on PHP it will not stop it, it has to be open basedir restriction. As it says, also upgrading to PHP 5.2.4 will also fix this.
Posted by RBBOT, 09-13-2007, 09:32 AM The same configuration settings at the mysql side will protect against that one too.
Posted by Patrick, 09-13-2007, 09:36 AM This is Redhat's official response to the exploit: "We do not consider these to be security issues. For more details see http://bugzilla.redhat.com/bugzilla/...i?id=169857#c1 and http://www.php.net/security-note.php"
Posted by StevenG, 09-13-2007, 11:38 PM If you don't have open_basedir set or safe_mode on, then there's no need to use mysql at all - upgrading php won't do anything in that case either. There is no exploit here as such, it's just sloppy permissions or a wide open php server that is going to get issues - there are dozens of ways that those servers are going to be targeted anyway, to give information that someone wants. Nothing new here, somebody just found a new way to read files and decided to post about it..
Posted by LoganNZ, 09-14-2007, 12:12 AM mod_security should protect against this type of attack if you add the correct rules no?
Posted by Tom P, 09-14-2007, 04:18 AM LoganNZ: As said before, if you have open_basedir correctly configured for each users directory then it won't work anyway.
Posted by jon-f, 09-14-2007, 08:59 AM yeah , after looking at it and talking to a few people its just a normal function of mysql. It will only write to world writable directories, so can a bunch of other things. That one on milw0rm though, I try to keep up with them open_base exploits as I still preffer to run php as nobody on most servers
Posted by Patrick, 09-14-2007, 09:13 AM What's your reason for running PHP as nobody? ... not looking for a debate, just curious.