Return-Path: 
 <users-return-3255-apmail-httpd-users-archive=httpd.apache.org@httpd.apache.org>
Delivered-To: apmail-httpd-users-archive@httpd.apache.org
Received: (qmail 78651 invoked by uid 500); 28 Feb 2002 19:03:49 -0000
Mailing-List: contact users-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@httpd.apache.org
list-help: <mailto:users-help@httpd.apache.org>
list-unsubscribe: <mailto:users-unsubscribe@httpd.apache.org>
list-post: <mailto:users@httpd.apache.org>
Delivered-To: mailing list users@httpd.apache.org
Received: (qmail 78640 invoked from network); 28 Feb 2002 19:03:48 -0000
Received: from spmler3.mail.eds.com (194.128.225.186)
  by daedalus.apache.org with SMTP; 28 Feb 2002 19:03:48 -0000
Received: from spmlir1.mail.eds.com (spmlir1-2.mail.eds.com [192.168.1.6])
	by spmler3.mail.eds.com (8.11.6/8.11.3) with ESMTP id g1SJ3gb01227
	for <users@httpd.apache.org>; Thu, 28 Feb 2002 19:03:42 GMT
Received: from nnse.eds.com (localhost [127.0.0.1])
	by spmlir1.mail.eds.com (8.11.6/8.11.3) with ESMTP id g1SJ3gt24470
	for <users@httpd.apache.org>; Thu, 28 Feb 2002 19:03:42 GMT
Received: from gbspm010.exgb01.exch.eds.com ([207.37.51.202])
	by nnse.eds.com (8.11.6/8.11.3) with ESMTP id g1SJ3gO12728
	for <users@httpd.apache.org>; Thu, 28 Feb 2002 19:03:42 GMT
Received: by GBSPM010 with Internet Mail Service (5.5.2653.19)
	id <D4802C2L>; Thu, 28 Feb 2002 19:03:38 -0000
Message-ID: <5F5FDD4B3580D511B3700002A57493F821C1A0@GBHBM201>
From: "Boyce, Nick" <nick.boyce@eds.com>
To: "'users@httpd.apache.org'" <users@httpd.apache.org>
Subject: RE: Apache exploit
Date: Thu, 28 Feb 2002 19:03:01 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

On 28 February 2002 18:06 Bill -OSX- Jones <sneex@mac.com> wrote :

> On Thursday, February 28, 2002, at 12:57  PM, Joe wrote:
> 
>> Our apache server was hacked into last night and our index.html file
replaced 
>> We are running  ver 1.3.17 with 
>>  http_core.c
[snip]
>>  mod_ssl.c
[snip]
>> /home/www/docroot/idiglobal/|ls
>> /home/www/docroot/idiglobal/ls
>> /home/www/docroot/idiglobal/ls|
>> /home/www/docroot/idiglobal/index.plls
>> /home/www/docroot/idiglobal/index.pl|ls
>> /home/www/docroot/idiglobal/index.pl;ls
>> [Thu Feb 28 07:37:14 2002] [error] [client 212.7.9.35] unknown 
>> directive
>> "########################################################################
>> ###"
>> in parsed doc /home/www/docroot/idiglobal/index.html
> 
> Hmmm ... since you've removed the actual 'hack' I can start jumping 
> to conclusions... You have SSI enabled and possibly are badly 
> handling CGI code?
> 
> Are you trusting user supplied vars?

I'm not trying to disagree with Bill - his suggestion looks right to me.
However ..

I note that you have mod_ssl installed - so you may want to know about
yesterday's (27/02/2002) mod_ssl security alert - it describes how an
obscure attack on an SSL-enabled Apache webserver is just conceivably
possible,  by a rogue browser equipped with a maliciously constructed client
digital certificate.  This certificate would have to have been signed by a
CA that your webserver trusts, so the attack *is* very very unlikely, but
even so ...

The problem is fixed by a new mod_ssl version released on 23/02/2002.

Here's the alert :

====================< snip >======================

Author: Ed Moyle

mod_ssl Buffer Overflow Condition (Update Available)
--------------------------------------------------------

SYNOPSIS

mod_ssl (www.modssl.org) is a commonly used Apache module that 
provides strong cryptography for the Apache web server.  The
module utilizes OpenSSL (formerly SSLeay) for the SSL implementation.
modssl versions prior to 2.8.7-1.3.23 (Feb 23, 2002) make use of the
underlying OpenSSL routines in a manner which could overflow a buffer
within the implementation.  This situation appears difficult to
exploit in a production environment, however, for reasons detailed
below.

CAUSE

The session caching mechanisms utilizing dbm and shared memory
utilize the OpenSSL routine i2d_SSL_SESSION, which "serializes" 
an SSL session into a format that can be stored in the session cache.
The OpenSSL docs inform us:

    When using i2d_SSL_SESSION(), the memory location pointed to by pp 
    must be large enough to hold the binary representation of the session.
    There is no known limit on the size of the created ASN1 representation,
    so the necessary amount of space should be obtained by first calling 
    i2d_SSL_SESSION() with pp=NULL, and obtain the size needed, then 
    allocate the memory and call i2d_SSL_SESSION() again. 

mod_ssl < the version listed above do not do this, however, and could
potentially lead to an overflow of the static buffer used by mod_ssl 
for holding the contents of the serialized session.

DETAILS

An example of the relevant mod_ssl source is listed below:

(mod_ssl < 2.8.7) (www.modssl.org)
 
ssl_util_ssl.h:
 
#define SSL_SESSION_MAX_DER 1024*10
 
 ssl_scache_dbm.c:
 
 BOOL ssl_scache_dbm_store(server_rec *s, UCHAR *id, int 
              idlen, time_t expiry, SSL_SESSION *sess) {
 
<snip>
 
 UCHAR ucaData[SSL_SESSION_MAX_DER];
 
<snip>
 
 ucp = ucaData;
 nData = i2d_SSL_SESSION(sess, &ucp);

 
MITIGATING FACTORS

This vulnerability is unlikely to be exploitable in a production 
environment. Since the buffer in question is the contents of the 
SSL session, exploitability of this scenario would be tied to 
increasing the size of the session.  The most obvious way of doing 
this would be through the use of client certificates.  Therefore, 
generating a really big client cert would overflow the buffer, and 
could potentially be used to run arbitrary code.  HOWEVER, these 
routines are only called AFTER SUCCESSFUL VERIFICATION of the client 
cert, which would mean that a CA *TRUSTED BY THE WEB SERVER* would have 
to issue the certificate in question.  In addition, both client cert 
auth and the dbm or shared memory session caching functionality would 
need to be enabled.  

ACKNOWLEDGEMENTS
Thanks to Graeme Tait, Apache guru, whose persistence and clever
analysis once again made all the difference.  Thanks to Ralf 
Engelschall for fixing this so quickly, and also for pointing out
that the problem applies also to the shared memory cache.

====================< snip >======================

> Nick Boyce
> EDS Southwest Solution Centre, Bristol, UK

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org