Vous êtes ici: index » cert » avis

Avis du CERT RENATER

Par défaut, cette page vous affichera les derniers messages envoyés par le CERT RENATER à la communauté. Vous pouvez affiner par année ou par type de message. Si aucun critère n'est précisé, seuls les derniers messages sont affichés

Date : Tue, 1 Mar 2016 17:53:21 +0100
Type : VULN
Sujet : CERT-Renater : 2016/VULN085 (OpenSSL : OpenSSL Security Advisory [1st March 2016])
===================================================================
                                   CERT-Renater

                       Note d'Information No. 2016/VULN085
_____________________________________________________________________

DATE                : 29/02/2016

HARDWARE PLATFORM(S): /

OPERATING SYSTEM(S): Systems running OpenSSL versions prior to 1.0.2g,
                                          1.0.1s.

======================================================================
https://www.openssl.org/news/secadv/20160301.txt
_____________________________________________________________________

OpenSSL Security Advisory [1st March 2016]
=========================================

NOTE: With this update, OpenSSL is disabling the SSLv2 protocol by
default, as well as removing SSLv2 EXPORT ciphers.  We strongly advise
against the use of SSLv2 due not only to the issues described below,
but to the other known deficiencies in the protocol as described at
https://tools.ietf.org/html/rfc6176


Cross-protocol attack on TLS using SSLv2 (DROWN) (CVE-2016-0800)
================================================================

Severity: High

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.

OpenSSL 1.0.2 users should upgrade to 1.0.2g
OpenSSL 1.0.1 users should upgrade to 1.0.1s

This issue was reported to OpenSSL on December 29th 2015 by Nimrod
Aviram and Sebastian Schinzel. The fix was developed by Viktor Dukhovni
and Matt Caswell of OpenSSL.


Double-free in DSA code (CVE-2016-0705)
=======================================

Severity: Low

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.

This issue affects OpenSSL versions 1.0.2 and 1.0.1.

OpenSSL 1.0.2 users should upgrade to 1.0.2g
OpenSSL 1.0.1 users should upgrade to 1.0.1s

This issue was reported to OpenSSL on February 7th 2016 by Adam Langley
(Google/BoringSSL) using libFuzzer. The fix was developed by Dr Stephen
Henson of OpenSSL.


Memory leak in SRP database lookups (CVE-2016-0798)
===================================================

Severity: Low

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.

This issue affects OpenSSL versions 1.0.2 and 1.0.1.

OpenSSL 1.0.2 users should upgrade to 1.0.2g
OpenSSL 1.0.1 users should upgrade to 1.0.1s

This issue was discovered on February 23rd 2016 by Emilia Käsper of
the OpenSSL development team. Emilia Käsper also developed the fix.


BN_hex2bn/BN_dec2bn NULL pointer deref/heap corruption (CVE-2016-0797)
======================================================================

Severity: Low

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.

This issue affects OpenSSL versions 1.0.2 and 1.0.1.

OpenSSL 1.0.2 users should upgrade to 1.0.2g
OpenSSL 1.0.1 users should upgrade to 1.0.1s

This issue was reported to OpenSSL on February 19th 2016 by Guido
Vranken.  The fix was developed by Matt Caswell of the OpenSSL
development team.

Fix memory issues in BIO_*printf functions (CVE-2016-0799)
==========================================================

Severity: Low

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.

This issue affects OpenSSL versions 1.0.2 and 1.0.1.

OpenSSL 1.0.2 users should upgrade to 1.0.2g
OpenSSL 1.0.1 users should upgrade to 1.0.1s

This issue was reported to OpenSSL on February 23rd by Guido Vranken.
The fix was developed by Matt Caswell of the OpenSSL development team.

Side channel attack on modular exponentiation (CVE-2016-0702)
=============================================================

Severity: Low

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
decryptions.

This issue affects OpenSSL versions 1.0.2 and 1.0.1.

OpenSSL 1.0.2 users should upgrade to 1.0.2g
OpenSSL 1.0.1 users should upgrade to 1.0.1s

This issue was reported to OpenSSL on Jan 8th 2016 by Yuval Yarom, The
University of Adelaide and NICTA, Daniel Genkin, Technion and Tel Aviv
University, and Nadia Heninger, University of Pennsylvania with more
information at http://cachebleed.info.  The fix was developed by Andy
Polyakov of OpenSSL.


Divide-and-conquer session key recovery in SSLv2 (CVE-2016-0703)
================================================================

Severity: High

This issue only affected versions of OpenSSL prior to March 19th 2015
at which time the code was refactored to address vulnerability
CVE-2015-0293.

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.

This issue affected OpenSSL versions 1.0.2, 1.0.1l, 1.0.0q, 0.9.8ze and
all earlier versions.  It was fixed in OpenSSL 1.0.2a, 1.0.1m, 1.0.0r
and 0.9.8zf (released March 19th 2015).

This issue was reported to OpenSSL on February 10th 2016 by David
Adrian and J.
Alex Halderman of the University of Michigan.  The underlying defect
had by then already been fixed by Emilia Käsper of OpenSSL on March 4th
2015.  The fix for this issue can be identified by commits ae50d827
(1.0.2a), cd56a08d (1.0.1m), 1a08063 (1.0.0r) and 65c588c (0.9.8zf).


Bleichenbacher oracle in SSLv2 (CVE-2016-0704)
==============================================

Severity: Moderate

This issue only affected versions of OpenSSL prior to March 19th 2015
at which time the code was refactored to address the vulnerability
CVE-2015-0293.

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.

This issue affected OpenSSL versions 1.0.2, 1.0.1l, 1.0.0q, 0.9.8ze and
all earlier versions.  It was fixed in OpenSSL 1.0.2a, 1.0.1m, 1.0.0r
and 0.9.8zf (released March 19th 2015).

This issue was reported to OpenSSL on February 10th 2016 by David
Adrian and J.
Alex Halderman of the University of Michigan.  The underlying defect
had by then already been fixed by Emilia Käsper of OpenSSL on March 4th
2015.  The fix for this issue can be identified by commits ae50d827
(1.0.2a), cd56a08d (1.0.1m), 1a08063 (1.0.0r) and 65c588c (0.9.8zf).

Note
====

As per our previous announcements and our Release Strategy
(https://www.openssl.org/policies/releasestrat.html), support for
OpenSSL version 1.0.1 will cease on 31st December 2016. No security
updates for that version will be provided after that date. Users of
1.0.1 are advised to upgrade.

Support for versions 0.9.8 and 1.0.0 ended on 31st December 2015. Those
versions are no longer receiving security updates.

References
==========

URL for this Security Advisory:
https://www.openssl.org/news/secadv/20160301.txt

Note: the online version of the advisory may be updated with additional
details over time.

For details of OpenSSL severity classifications please see:
https://www.openssl.org/policies/secpolicy.html

==========================================================
Serveur de référence du CERT-Renater
https://services.renater.fr/ssi/
==========================================================
+ CERT-RENATER          | tel : 01-53-94-20-44           +
+ 23 - 25 Rue Daviel    | fax : 01-53-94-20-41           +
+ 75013 Paris           | email: cert@support.renater.fr +
==========================================================

[An attachment of type application/pkcs7-signature was included here]