COMMAND

	mod_ssl Buffer Overflow Condition

SYSTEMS AFFECTED

	versions prior to 2.8.7-1.3.23

PROBLEM

	Ed Moyle found following :
	

	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.

SOLUTION

	 Update (05 March 2002)

	 ======

	

	Patch : Apache-SSL 1.3.22+1.47 [http://www.apache-ssl.org/]