mod_ssl Buffer Overflow Condition (Update Available)

[Ed Moyle <emoyle () scsnet csc com>]

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.