This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 649304 - (CVE-2010-3864) CVE-2010-3864 OpenSSL TLS extension parsing race condition
CVE-2010-3864 OpenSSL TLS extension parsing race condition
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
high Severity high
: ---
: ---
Assigned To: Red Hat Product Security
public=20101116,reported=20101103,sou...
: Security
Depends On: 649306 649307 653969 1127896
Blocks:
  Show dependency treegraph
 
Reported: 2010-11-03 10:00 EDT by Josh Bressers
Modified: 2015-08-19 04:58 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-04-10 04:18:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


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

  None (edit)
Description Josh Bressers 2010-11-03 10:00:45 EDT
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.
Comment 3 Josh Bressers 2010-11-03 10:56:44 EDT
Acknowledgements:

Red Hat would like to thank Rob Hulswit for reporting this issue.
Comment 4 Mark J. Cox (Product Security) 2010-11-04 10:24:13 EDT
Created attachment 457804 [details]
latest patches
Comment 5 Josh Bressers 2010-11-12 09:39:36 EST
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 (Product Security) 2010-11-15 09:37:38 EST
Statement:

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 (Product Security) 2010-11-15 10:32:02 EST
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 (Product Security) 2010-11-15 10:52:26 EST
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 (Product Security) 2010-11-16 09:21:40 EST
Public via
http://openssl.org/news/secadv_20101116.txt
Comment 10 Tomas Hoger 2010-11-16 09:42:44 EST
Created openssl tracking bugs for this issue

Affects: fedora-all [bug 653969]
Comment 11 errata-xmlrpc 2010-11-16 11:20:09 EST
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.