Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
From: Ed Moyle (emoylescsnet.csc.com)
Date: Wed Feb 27 2002 - 12:05:34 CST

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    mod_ssl Buffer Overflow Condition (Update Available)


    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


    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.


    An example of the relevant mod_ssl source is listed below:

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


    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.

    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.