---

OpenSSL and SSLeay Security Alert

Ben Laurie posted to
BUGTRAQ:

It was recently realised that packages that use SSLeay and
OpenSSL may suffer from a security problem: under some
circumstances, SSL sessions can be reused in a different context
from their original one. This may allow access controls based on
client certificates to be bypassed.

Unfortunately, before the the problem was fully understood, it
was discussed on various public lists. The OpenSSL team have
therefore decided to release an interim version of OpenSSL which
addresses the problem by disabling session reuse except in limited
circumstances (see below).

A future version will deal with the problem more elegantly by
redoing verification on reused sessions when necessary.

Although this problem is not strictly a defect in OpenSSL, it is
rather tricky for applications to be coded correctly to avoid the
problem due to the sketchy nature of SSLeay/OpenSSL documentation.
We therefore decided to protect applications from within
OpenSSL.

The problem
———–

SSL sessions include a session ID which allows initial setup to
be bypassed once a session has been established between a client
and server. This session ID, when presented by the client, causes
the same master key to be used as was used on the previous
connection, thus saving considerable session setup time.

When the session is reused in this manner, all access controls
based on client certificates are bypassed, on the grounds that the
original session would have made the necessary checks.

Unfortunately, the lack of documentation has resulted in the
caching structures being used in certain applications without
appropriate care being taken to assure that the cached sessions are
only available at the appropriate moments.

As a result it is sometimes possible for a specially written SSL
client to fraudulently obtain an SSL connection which requires
access control by reusing a previous session which had different or
no access control.

The problem affects servers which support session reuse and
which have multiple virtual hosts served from a single server,
where some virtual hosts use differing client server verifications.
Note that “different” includes no verification on some hosts, and
verification on others, or different CAs for different hosts.

In order to exploit this problem carefully written client
software would need to be written. The attacker would need
considerable knowledge of the SSL protocol. Standard web browsers
will not and cannot be made to use SSL in this way.

Affected software
—————–

All server software using SSLeay or versions of OpenSSL prior to
version 0.9.2b that support multiple virtual hosts with different
client certificate verification may be vulnerable.

This includes, but is not limited to:

Apache-SSL      http://www.apache-ssl.org/
mod_ssl         http://www.engelschall.com/sw/mod_ssl/

Raven           http://www.covalent.net/

Stronghold      http://www.c2.net/

The solution
————

Download OpenSSL 0.9.2b (see http://www.openssl.org) and build it
in the usual way.

Check the application for updates, and download those, too (NB:
this step is not necessarily required, the updated library will fix
the problem). The versions of the applications listed above that
you should use are:

Apache_SSL 1.3.4+1.32
mod_ssl 2.2.6-1.3.4
Raven 1.4.0
Stronghold 2.4.2

Rebuild the application (if needed).

If you are an application author, you should look in to the use
of SSL_set_session_id_context(), which can be used to reenable
session reuse when appropriate.

Known exploits
————–

There are no known exploits of this security hole.

Ben Laurie, for the OpenSSL team.


http://www.apache-ssl.org/ben.html

“My grandfather once told me that there are two kinds of people:
those who work and those who take the credit. He told me to try to
be in the first group; there was less competition there.”
– Indira Gandhi

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends, & analysis