Package: apache-ssl Version: 1.3.26.1+1.48-0woody3 Severity: grave Tags: security Justification: user security hole
I'm using debian woody, with the apache-ssl server, and several times over the past two months I've seen the server start using 100% cpu (per process; sometimes just one apache-ssl process is affected; sometimes as many as 12!). I'm filing this with a rather aggressive priority since it appears to be a remotely accessible DoS exploit, though no user data seems to be compromised. When this happens, I've looked at apache's access.log, and each time I've found requests that look like 213.148.18.198 - - [07/Jun/2005:01:20:55 -0700] "GET / HTTP/1.1" 200 7090 "http://www.qptv.ru" "MSIE 6.0" 213.148.18.198 - - [07/Jun/2005:01:20:55 -0700] "\t\x15\x10" 400 - "-" "-" repeated over and over, near the time I estimate the server started sucking up 100% cpu. Always from that exact IP address (213.148.18.198, for which I can find no information), and always, a pair of requests, "GET /" followed by "\t\x15\x10". I'd think this has been reported before, but google turns up no hits for the offending IP address. When this happens, I've tried strace'ing the apache-ssl process, and all it does is set timers and then wake up with SIGITIMER repeatedly. -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux skynet 2.4.18-686 #1 Sun Apr 14 11:32:47 EST 2002 i686 Locale: LANG=C, LC_CTYPE=C Versions of packages apache-ssl depends on: ii apache-common 1.3.26-0woody6 Support files for all Apache webse ii dpkg 1.9.21 Package maintenance system for Deb ii libc6 2.2.5-11.8 GNU C Library: Shared libraries an ii libdb2 2:2.7.7.0-7 The Berkeley database routines (ru ii libexpat1 1.95.2-6 XML parsing C library - runtime li ii libssl0.9.6 0.9.6c-2.woody.7 SSL shared libraries ii logrotate 3.5.9-8 Log rotation utility ii mime-support 3.18-1.3 MIME files 'mime.types' & 'mailcap ii openssl 0.9.6c-2.woody.7 Secure Socket Layer (SSL) binary a ii perl 5.6.1-8.9 Larry Wall's Practical Extraction ii perl [perl5] 5.6.1-8.9 Larry Wall's Practical Extraction -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]