The following security advisory was reported by OpenBSD: OpenBSD 5.4 errata 8, Apr 12, 2014: A use-after-free race condition in OpenSSL's read buffer may permit an attacker to inject data from one connection into another. Reference: http://ftp.openbsd.org/pub/OpenBSD/patches/5.4/common/008_openssl.patch http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse
Analysis: openssl does its own memory management and maintains a LIFO freelist of buffers available. In ssl3_read_bytes(), it released buffer even if there is some data available inside it. Later in s3_pkt.c:1058, ssl3_release_read_buffer() is called to allocate another buffer. In a single threaded application the same buffer would be allocated and openssl continues to read valid data from it. However in a multi-thread context or when openssl is compiled with OPENSSL_NO_BUF_FREELISTS which makes it uses system memory management, when a buffer is re-malloced, the old data is gone, at this point openssl bails out and TLS session is broken. I don't think this is exploitable. Could be exploitable only if the re-malloced buffer is not initialized and sent out on the wire, but I don't see that happening anywhere.
I don't think this is exploitable. The concurrent thread (if using the data properly) would not reuse the buffer contents and will overwrite it with its own ciphertext data. This will cause parsing error in the original thread when it will try to read the data later.
CVE-2010-5298 was assigned to this issue.
Upstream bug: https://rt.openssl.org/Ticket/Display.html?id=2167&user=guest&pass=guest Upstream commit: https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=94d1f4b
The support for freelist was introduced as part of the "Memory saving patch" added in OpenSSL version 1.0.0: https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=8671b89 Therefore, this issue does not affect openssl packages in Red Hat Enterprise Linux 5 or earlier, that are based on upstream version 0.9.8 and earlier and does not contain affected code. This problem can only occur when application enables SSL_MODE_RELEASE_BUFFERS mode, which is not the default. As noted in bug 1093837 comment 1, few applications shipped as part of Red Hat Enterprise Linux 6 do so. Additionally, single-threaded applications using this mode are usually not affected either. The buffer re-used is read buffer where packet data is stored. If the TLS/SSL connection is already established and encrypted data is expected, encrypted data from different concurrent TLS/SSL would not decrypt successfully. Data re-use during handshake may proceed further, but TLS/SSL already contains mechanisms to prevent handshake from completing if any data is injected. There currently does not seem to be any reports to indicate conditions under which this can have worse impact than aborted connection.
Statement: This issue did not affect the openssl packages shipped with Red Hat Enterprise Linux 5.
Created openssl tracking bugs for this issue: Affects: fedora-all [bug 1096233]
Created mingw-openssl tracking bugs for this issue: Affects: fedora-all [bug 1096234]
Fixed upstream in OpenSSL 1.0.1h and 1.0.0m. External References: https://www.openssl.org/news/secadv_20140605.txt
This issue has been addressed in following products: Red Hat Enterprise Linux 6 Via RHSA-2014:0625 https://rhn.redhat.com/errata/RHSA-2014-0625.html
This issue has been addressed in following products: Red Hat Storage 2.1 Via RHSA-2014:0628 https://rhn.redhat.com/errata/RHSA-2014-0628.html
openssl-1.0.1e-38.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
openssl-1.0.1e-38.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
This issue has been addressed in following products: Red Hat Enterprise Linux 7 Via RHSA-2014:0679 https://rhn.redhat.com/errata/RHSA-2014-0679.html