A race condition flaw has been found in the OpenSSL TLS server extension code parsing, which on affected servers, could lead to arbitrary code execution. All versions of OpenSSL supporting TLS extensions contain this vulnerability including OpenSSL 0.9.8j and later and 1.0.0, 1.0.0a releases. Any OpenSSL based TLS server is vulnerable if it is multi-threaded and uses OpenSSL's internal caching mechanism. Servers that are multi-process and/or disable internal session caching are NOT affected.
Acknowledgements: Red Hat would like to thank Rob Hulswit for reporting this issue.
Created attachment 457804 [details] latest patches
Any OpenSSL based TLS server is vulnerable if it is multi-threaded and uses OpenSSL's internal caching mechanism. Servers that are multi-process and/or disable internal session caching are NOT affected. It should be noted that this flaw does not affect the Apache HTTP Server as used with OpenSSL as it never uses the internal OpenSSL internal session cache.
Statement: This issue does not affect the versions of OpenSSL as shipped with Red Hat Enterprise Linux versions before Enterprise Linux 6.
Technical details: Upstream OpenSSL fixed code in two locations. Red Hat OpenSSL packages are compiled without Elliptic Curve cryptography support, and so only the TLS server name extension code is vulnerable. This code was first introduced to the OpenSSL version shipped with Red Hat Enterprise Linux 6. In a technical analysis of this code, and by testing, we believe even with an affected application that this is unlikely to be able to be easily remotely exploited. The affected code in ssl/t1_lib.c looks like this: case TLSEXT_NAMETYPE_host_name: if (s->session->tlsext_hostname == NULL) { if (len > TLSEXT_MAXLEN_host_name || ((s->session->tlsext_hostname = OPENSSL_malloc(len+1)) == NULL)) { ... return ... } memcpy(s->session->tlsext_hostname, sdata, len); If using OpenSSL in a multithreaded server, and using the internal session caching, then s->session is shared between threads. If the application is not doing any locking of its own, then you can get a race situation setting tlsext_hostname. That's because you have code that effectively looks like this, where ptr is shared: if (ptr == NULL) { ptr = malloc(length); memcpy(ptr, data, length); } So there is a short period between the NULL check and the malloc during which other threads could also enter this section. You also then have a second short period between the malloc and memcpy during which a thread could end up doing a malloc of a smaller size buffer which another threads memcpy will overflow. In practice, on a single processor, this is unlikely to be triggerable as it requires two context switches between threads within a very small number of instructions. In our tests we were unable to trigger this without locally artificially slowing down the threads. It may be more plausible you can win these races on multi-processor machines. The length of the buffers allocated is limited to 256 characters, so winning the races would allow an attacker to write arbitrary characters beyond a heap allocated buffer by up to 255 characters.
Note: Sometimes even code like that above can be rendered harmless by the compiler -- gcc could decide to use a temporary variable and not re-read the value of 'ptr' between the malloc and memcpy. But we checked and unfortunately this was not the case in the OpenSSL binary version as we shipped in Red Hat Enterprise Linux 6.
Public via http://openssl.org/news/secadv_20101116.txt
Created openssl tracking bugs for this issue Affects: fedora-all [bug 653969]
This issue has been addressed in following products: Red Hat Enterprise Linux 6 Via RHSA-2010:0888 https://rhn.redhat.com/errata/RHSA-2010-0888.html