Your message dated Wed, 8 Jun 2005 11:36:41 +1000 (EST)
with message-id <[EMAIL PROTECTED]>
and subject line Bug#312390: apache-ssl: apache-ssl uses 100% cpu after bogus   
   http request
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--------------------------------------
Received: (at submit) by bugs.debian.org; 7 Jun 2005 21:51:10 +0000
>From [EMAIL PROTECTED] Tue Jun 07 14:51:10 2005
Return-path: <[EMAIL PROTECTED]>
Received: from skynet.ginzton.net (mail.ginzton.net) [69.36.243.55] 
        by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
        id 1DflyY-0003n8-00; Tue, 07 Jun 2005 14:51:10 -0700
Received: from localhost (localhost [127.0.0.1])
  (uid 1000)
  by mail.ginzton.net with local; Tue, 07 Jun 2005 14:51:09 -0700
From: Matt Ginzton <[EMAIL PROTECTED]>
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
Subject: apache-ssl: apache-ssl uses 100% cpu after bogus http request
X-Mailer: reportbug 1.50
Date: Tue, 07 Jun 2005 14:51:09 -0700
Message-ID: <[EMAIL PROTECTED]>
X-BadReturnPath: [EMAIL PROTECTED] rewritten as [EMAIL PROTECTED]
  using "From" header
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 
        (1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE 
        autolearn=no version=2.60-bugs.debian.org_2005_01_02
X-Spam-Level: 

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 


---------------------------------------
Received: (at 312390-done) by bugs.debian.org; 8 Jun 2005 01:37:12 +0000
>From [EMAIL PROTECTED] Tue Jun 07 18:37:12 2005
Return-path: <[EMAIL PROTECTED]>
Received: from loki.0c3.net [69.0.240.48] 
        by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
        id 1DfpVI-0005bZ-00; Tue, 07 Jun 2005 18:37:12 -0700
Received: from localhost
        ([127.0.0.1] helo=mail.0c3.net ident=www-data)
        by loki.0c3.net with esmtp (Exim 4.34)
        id 1DfpUn-0000Yv-9s
        for [EMAIL PROTECTED]; Tue, 07 Jun 2005 19:36:41 -0600
Received: from 203.49.196.168
        (SquirrelMail authenticated user adconrad)
        by mail.0c3.net with HTTP;
        Wed, 8 Jun 2005 11:36:41 +1000 (EST)
Message-ID: <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Date: Wed, 8 Jun 2005 11:36:41 +1000 (EST)
Subject: Re: Bug#312390: apache-ssl: apache-ssl uses 100% cpu after bogus 
     http request
From: "Adam Conrad" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
User-Agent: SquirrelMail/1.5.1 [CVS]
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: 8bit
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Mail-From: [EMAIL PROTECTED]
X-SA-Exim-Scanned: No (on loki.0c3.net); SAEximRunCond expanded to false
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 
        (1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-5.0 required=4.0 tests=BAYES_01,HAS_BUG_NUMBER 
        autolearn=no version=2.60-bugs.debian.org_2005_01_02
X-Spam-Level: 

Matt Ginzton wrote:
>
> 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.

A DoS != an exploit, in most people's minds, just a serious annoyance. 
While annoyances like this may be fixed in the course of stable updates,
they will generally never get fixed in an "oldstable" release.

Since Sarge was released as stable a couple of days ago and Woody has
moved to "oldstable" status, one would only expect real security exploits
(remote execution, privelege escalation, etc) to be fixed in woody
packages from here on in.

I'd recommend upgrading to Sarge at your earliest convenience.  Many
improvements have been made there, including a (generally) much more
stable set of both apache1.3 and apache2 (which I recommend upgrading to
if you can) packages.

... Adam



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to