[OpenWrt-Devel] [CC 15.05] openssl: Security update (9 CVEs)

jow at openwrt.org jow at openwrt.org
Tue Mar 1 10:52:09 EST 2016

The openssl package has been rebuilt and was uploaded to the Chaos
Calmer 15.05 repository due to multiple security issues.


1.0.2f-1 => 1.0.2g-1


[Tue, 1 Mar 2016 15:18:24 +0000 f4368a7]


s2_srvr.c overwrite the wrong bytes in the master-key when applying
Bleichenbacher protection for export cipher suites. This provides a
Bleichenbacher oracle, and could potentially allow more efficient
variants of the DROWN attack.


s2_srvr.c did not enforce that clear-key-length is 0 for non-export
ciphers. If clear-key bytes are present for these ciphers, they
*displace* encrypted-key bytes. This leads to an efficient
divide-and-conquer key recovery attack: if an eavesdropper has
intercepted an SSLv2 handshake, they can use the server as an oracle to
determine the SSLv2 master-key, using only 16 connections to the server
and negligible computation. More importantly, this leads to a more
efficient version of DROWN that is effective against non-export
ciphersuites, and requires no significant computation.


A side-channel attack was found which makes use of cache-bank conflicts
on the Intel Sandy-Bridge microarchitecture which could lead to the
recovery of RSA keys. The ability to exploit this issue is limited as it
relies on an attacker who has control of code in a thread running on the
same hyper- threaded core as the victim thread which is performing


The internal |fmtstr| function used in processing a "%s" format string
in the BIO_*printf functions could overflow while calculating the length
of a string and cause an OOB read when printing very long strings.
Additionally the internal |doapr_outch| function can attempt to write to
an OOB memory location (at an offset from the NULL pointer) in the event
of a memory allocation failure. In 1.0.2 and below this could be caused
where the size of a buffer to be allocated is greater than INT_MAX. E.g.
this could be in processing a very long "%s" format string. Memory leaks
can also occur. The first issue may mask the second issue dependent on
compiler behaviour. These problems could enable attacks where large
amounts of untrusted data is passed to the BIO_*printf functions. If
applications use these functions in this way then they could be
vulnerable. OpenSSL itself uses these functions when printing out
human-readable dumps of ASN.1 data. Therefore applications that print
this data could be vulnerable if the data is from untrusted sources.
OpenSSL command line applications could also be vulnerable where they
print out ASN.1 data, or if untrusted data is passed as command line
arguments. Libssl is not considered directly vulnerable. Additionally
certificates etc received via remote connections via libssl are also
unlikely to be able to trigger these issues because of message size
limits enforced within libssl.


In the BN_hex2bn function the number of hex digits is calculated using
an int value |i|. Later |bn_expand| is called with a value of |i * 4|.
For large values of |i| this can result in |bn_expand| not allocating
any memory because |i * 4| is negative. This can leave the internal
BIGNUM data field as NULL leading to a subsequent NULL ptr deref. For
very large values of |i|, the calculation |i * 4| could be a positive
value smaller than |i|. In this case memory is allocated to the internal
BIGNUM data field, but it is insufficiently sized leading to heap
corruption. A similar issue exists in BN_dec2bn. This could have
security consequences if BN_hex2bn/BN_dec2bn is ever called by user
applications with very large untrusted hex/dec data. This is anticipated
to be a rare occurrence. All OpenSSL internal usage of these functions
use data that is not expected to be untrusted, e.g. config file data or
application command line arguments. If user developed applications
generate config file data based on untrusted data then it is possible
that this could also lead to security consequences. This is also
anticipated to be rare.


The SRP user database lookup method SRP_VBASE_get_by_user had confusing
memory management semantics; the returned pointer was sometimes newly
allocated, and sometimes owned by the callee. The calling code has no
way of distinguishing these two cases. Specifically, SRP servers that
configure a secret seed to hide valid login information are vulnerable
to a memory leak: an attacker connecting with an invalid username can
cause a memory leak of around 300 bytes per connection. Servers that do
not configure SRP, or configure SRP but do not configure a seed are not
vulnerable. In Apache, the seed directive is known as
SSLSRPUnknownUserSeed. To mitigate the memory leak, the seed handling in
SRP_VBASE_get_by_user is now disabled even if the user has configured a
seed. Applications are advised to migrate to SRP_VBASE_get1_by_user.
However, note that OpenSSL makes no strong guarantees about the
indistinguishability of valid and invalid logins. In particular,
computations are currently not carried out in constant time.


A double free bug was discovered when OpenSSL parses malformed DSA
private keys and could lead to a DoS attack or memory corruption for
applications that receive DSA private keys from untrusted sources. This
scenario is considered rare.


A cross-protocol attack was discovered that could lead to decryption of
TLS sessions by using a server supporting SSLv2 and EXPORT cipher suites
as a Bleichenbacher RSA padding oracle. Note that traffic between
clients and non- vulnerable servers can be decrypted provided another
server supporting SSLv2 and EXPORT ciphers (even with a different
protocol such as SMTP, IMAP or POP) shares the RSA keys of the
non-vulnerable server. This vulnerability is known as DROWN
(CVE-2016-0800). Recovering one session key requires the attacker to
perform approximately 2^50 computation, as well as thousands of
connections to the affected server. A more efficient variant of the
DROWN attack exists against unpatched OpenSSL servers using versions
that predate 1.0.2a, 1.0.1m, 1.0.0r and 0.9.8zf released on 19/Mar/2015
(see CVE-2016-0703 below). Users can avoid this issue by disabling the
SSLv2 protocol in all their SSL/TLS servers, if they've not done so
already. Disabling all SSLv2 ciphers is also sufficient, provided the
patches for CVE-2015-3197 (fixed in OpenSSL 1.0.1r and 1.0.2f) have been
deployed. Servers that have not disabled the SSLv2 protocol, and are not
patched for CVE-2015-3197 are vulnerable to DROWN even if all SSLv2
ciphers are nominally disabled, because malicious clients can force the
use of SSLv2 with EXPORT ciphers. OpenSSL 1.0.2g and 1.0.1s deploy the
following mitigation against DROWN: SSLv2 is now by default disabled at
build-time. Builds that are not configured with "enable-ssl2" will not
support SSLv2. Even if "enable-ssl2" is used, users who want to
negotiate SSLv2 via the version-flexible SSLv23_method() will need to
explicitly call either of: SSL_CTX_clear_options(ctx, SSL_OP_NO_SSLv2);
or SSL_clear_options(ssl, SSL_OP_NO_SSLv2); as appropriate. Even if
either of those is used, or the application explicitly uses the
version-specific SSLv2_method() or its client or server variants, SSLv2
ciphers vulnerable to exhaustive search key recovery have been removed.
Specifically, the SSLv2 40-bit EXPORT ciphers, and SSLv2 56-bit DES are
no longer available. In addition, weak ciphers in SSLv3 and up are now
disabled in default builds of OpenSSL. Builds that are not configured
with "enable-weak-ssl-ciphers" will not provide any "EXPORT" or "LOW"
strength ciphers.

[Tue, 1 Mar 2016 08:14:46 +0000 dd7cc4d]

OpenSSL moves old versions of the library from
http://www.openssl.org/source/ to
http://www.openssl.org/source/old/$version/ breaking the old links. That
behavior breaks the OpenWRT-build every time OpenSSL releases a new

This patch adds http://www.openssl.org/source/old/$version/ to the
PKG_SOURCE_URL of OpenSSL to avoid breaking the build whenever OpenSSL
releases a new version.

Reviewed-by: Alexander Dahl <post at lespocky.de>


 package/libs/openssl/Makefile                 |    9 ++++++---
 .../patches/110-optimize-for-size.patch       |    2 +-
 .../libs/openssl/patches/150-no_engines.patch |   18 ++++++++---------
 .../openssl/patches/200-parallel_build.patch  |    4 ++--
 4 files changed, 18 insertions(+), 15 deletions(-)


 * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3197
 * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0702
 * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0703
 * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0704
 * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0705
 * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0797
 * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0798
 * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0799
 * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0800
 * http://git.openwrt.org/?p=15.05/openwrt.git;a=commit;h=dd7cc4da808d5a73eb58b1730dba5d65c0614ca7
 * http://git.openwrt.org/?p=15.05/openwrt.git;a=commit;h=f4368a72353194fbe998a02baeb3690d3a83174b
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org

More information about the openwrt-devel mailing list