Thank you Victor for the detailed answer. I still don't understand: Does the
vulnerability affect TLS *cliens*?
Thanks.
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
