[24443] in bugtraq
mod_ssl Buffer Overflow Condition (Update Available)
daemon@ATHENA.MIT.EDU (Ed Moyle)
Wed Feb 27 18:58:49 2002
Date: Wed, 27 Feb 2002 13:05:34 -0500
From: Ed Moyle <emoyle@scsnet.csc.com>
To: bugtraq@securityfocus.com
Message-id: <3BD76687A1CBD74097E37CB67263AE973558BB@scsetbmail.scsnet.csc.com>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Content-class: urn:content-classes:message
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.
