'mod_ssl' Security Package for Apache Web Server Has Buffer Overflow That Can Be Triggered By Remote Users
|
Date: Feb 26 2002
|
Impact: Execution of arbitrary code via network
|
Fix Available: Yes
Vendor Confirmed: Yes
|
Version(s): prior to 2.8.7
|
Description: A vulnerability was reported in the 'mod_ssl' package for the Apache web server. A remote user may be able to overflow a buffer. The potential impact is not yet know.
It is reported that a remote user may be able to trigger a buffer overflow in the DBM and SHMHT session cache by using very large
certificate chains. This is reportedly due to the unbounded nature of ASN.1 representations that could overflow a large but statically
allocated buffer.
It is not yet clear if remote code execution is feasible.
|
Impact: A remote user may be able to trigger a buffer overflow in mod_ssl. It is not yet clear if remote code execution is feasible.
|
Solution: Upgrade to version 2.8.7, available at:
http://www.modssl.org/source/mod_ssl-2.8.7-1.3.23.tar.gz
|
Vendor URL: www.modssl.org/ (Links to External Site)
|
Cause: Boundary error
|
Underlying OS: Linux (Any), UNIX (Any)
|
Reported By: Ed Moyle <emoyle@scsnet.csc.com>
|
Message History:
This archive entry has one or more follow-up message(s) listed below.
|
Source Message Contents
|
Date: Mon, 25 Feb 2002 11:28:58 -0500
From: Ed Moyle <emoyle@scsnet.csc.com>
Subject: second opinion regarding mod-ssl BO...
|
Howdy.
I am currently in the process of writing this up, and I'd like a second opinion on exploitability (mo
dssl team fixed w/ Sat's release):
(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, SS
> L_SESSION *sess) {
<snip>
> UCHAR ucaData[SSL_SESSION_MAX_DER];
<snip>
> ucp = ucaData;
> nData = i2d_SSL_SESSION(sess, &ucp);
relevant openssl docs (from http://www.openssl.org/docs/ssl/d2i_SSL_SESSION.html):
> 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.
I contend that the only way to exploit this is to generate a trusted client cert that has embedded sh
ell code in it (a difficult task
at best). Can anybody out there in the vast wide ether provide other opinions on exploitability sce
narios?
-E
|
|
