Bug 649304 (CVE-2010-3864) - CVE-2010-3864 OpenSSL TLS extension parsing race condition
Summary: CVE-2010-3864 OpenSSL TLS extension parsing race condition
Alias: CVE-2010-3864
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 649306 649307 653969 1127896
TreeView+ depends on / blocked
Reported: 2010-11-03 14:00 UTC by Josh Bressers
Modified: 2023-05-12 16:54 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-04-10 08:18:51 UTC

Attachments (Terms of Use)
latest patches (5.50 KB, patch)
2010-11-04 14:24 UTC, Mark J. Cox
no flags Details | Diff

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2010:0888 0 normal SHIPPED_LIVE Important: openssl security update 2010-11-16 16:19:56 UTC

Description Josh Bressers 2010-11-03 14:00:45 UTC
A race condition flaw has been found in the OpenSSL TLS server extension
code parsing, which on affected servers, could lead to arbitrary code

All versions of OpenSSL supporting TLS extensions contain this
vulnerability including OpenSSL 0.9.8j and later and 1.0.0, 1.0.0a

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.

Comment 3 Josh Bressers 2010-11-03 14:56:44 UTC

Red Hat would like to thank Rob Hulswit for reporting this issue.

Comment 4 Mark J. Cox 2010-11-04 14:24:13 UTC
Created attachment 457804 [details]
latest patches

Comment 5 Josh Bressers 2010-11-12 14:39:36 UTC
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.

Comment 6 Mark J. Cox 2010-11-15 14:37:38 UTC

This issue does not affect the versions of OpenSSL as shipped with Red Hat Enterprise Linux versions before Enterprise Linux 6.

Comment 7 Mark J. Cox 2010-11-15 15:32:02 UTC
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.

Comment 8 Mark J. Cox 2010-11-15 15:52:26 UTC
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.

Comment 9 Mark J. Cox 2010-11-16 14:21:40 UTC
Public via

Comment 10 Tomas Hoger 2010-11-16 14:42:44 UTC
Created openssl tracking bugs for this issue

Affects: fedora-all [bug 653969]

Comment 11 errata-xmlrpc 2010-11-16 16:20:09 UTC
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

Note You need to log in before you can comment on or make changes to this bug.