OpenSSL and SSLeay Security AlertMar 23, 1999, 12:24 (1 Talkback[s])
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.
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.
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:
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:
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.
There are no known exploits of this security hole.
Ben Laurie, for the OpenSSL team.
"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."