On Sun, Nov 21, 2010 at 04:40:09PM +0200, r rubin wrote:
> Hello,
>
> In the vulnerability detail, it is mentioned that:
> ?Any OpenSSL based TLS *server* is vulnerable".
> Does this mean that OpenSSL-based TLS *client* applications aren't
> vulnerable at all?
>
> Sorry if this is an obvious question, but as a very OpenSSL beginner I can't
> count on my own knowledge...
The problem code was in ssl_parse_clienthello_tlsext(). Instead
of allocating a buffer, copying data into it, verifying it, and
as a *last* step setting the session state to point at the already
initialized/verified buffer, the code first assigned the allocated
buffer to the session, and then wrote to it. This was subject to race
conditions between server threads. If the only update of the session
state were pointer updates and never updates of the referenced buffers,
the code would have been thread safe.
The fix chosen was to avoid all TLS extension driven updates in resumed
sessions, as resumed sessions should not be specifying conflicting values
for the various TLS extensions. The fix added checks for duplicate updates
during non-resumed session construction and ran into an issue with EC
point formats, because apparently (and here I don't know the details)
these can already be set by the time the client's extension is parsed.
Hence the additional patch in:
http://cvs.openssl.org/chngview?cn=19998
Do not deploy 1.0.0b without this patch.
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
