FreeBSD-SA-16:17.openssl

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

=============================================================================
FreeBSD-SA-16:17.openssl                                    Security Advisory
                                                          The FreeBSD Project

Topic:          Multiple OpenSSL vulnerabilities

Category:       contrib
Module:         openssl
Announced:      2016-05-04
Credits:        OpenSSL Project
Affects:        All supported versions of FreeBSD.
Corrected:      2016-05-03 18:54:20 UTC (stable/10, 10.3-STABLE)
                2016-05-04 15:25:47 UTC (releng/10.3, 10.3-RELEASE-p2)
                2016-05-04 15:26:23 UTC (releng/10.2, 10.2-RELEASE-p16)
                2016-05-04 15:27:09 UTC (releng/10.1, 10.1-RELEASE-p33)
                2016-05-04 06:53:02 UTC (stable/9, 9.3-STABLE)
                2016-05-04 15:27:09 UTC (releng/9.3, 9.3-RELEASE-p41)
CVE Name:       CVE-2016-2105, CVE-2016-2106, CVE-2016-2107, CVE-2016-2109,
                CVE-2016-2176

For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit .

I.   Background

FreeBSD includes software from the OpenSSL Project.  The OpenSSL Project is
a collaborative effort to develop a robust, commercial-grade, full-featured
Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3)
and Transport Layer Security (TLS v1) protocols as well as a full-strength
general purpose cryptography library.

II.  Problem Description

The padding check in AES-NI CBC MAC was rewritten to be in constant time
by making sure that always the same bytes are read and compared against
either the MAC or padding bytes. But it no longer checked that there was
enough data to have both the MAC and padding bytes. [CVE-2016-2107]

An overflow can occur in the EVP_EncodeUpdate() function which is used for
Base64 encoding of binary data. [CVE-2016-2105]

An overflow can occur in the EVP_EncryptUpdate() function, however it is
believed that there can be no overflows in internal code due to this problem.
[CVE-2016-2106]

When ASN.1 data is read from a BIO using functions such as d2i_CMS_bio()
a short invalid encoding can casuse allocation of large amounts of memory
potentially consuming excessive resources or exhausting memory.
[CVE-2016-2109]

ASN1 Strings that are over 1024 bytes can cause an overread in applications
using the X509_NAME_oneline() function on EBCDIC systems. [CVE-2016-2176]
FreeBSD does not run on any EBCDIC systems and therefore is not affected.

III. Impact

A MITM attacker can use a padding oracle attack to decrypt traffic
when the connection uses an AES CBC cipher and the server support
AES-NI. [CVE-2016-2107]

If an attacker is able to supply very large amounts of input data then a
length check can overflow resulting in a heap corruption. [CVE-2016-2105]

Any application parsing untrusted data through d2i BIO functions are vulnerable
to memory exhaustion attack. [CVE-2016-2109]  TLS applications are not affected.

IV.  Workaround

No workaround is available.

V.   Solution

Perform one of the following:

1) Upgrade your vulnerable system to a supported FreeBSD stable or
release / security branch (releng) dated after the correction date.

Restart all daemons that use the library, or reboot the system.

2) To update your vulnerable system via a binary patch:

Systems running a RELEASE version of FreeBSD on the i386 or amd64
platforms can be updated via the freebsd-update(8) utility:

# freebsd-update fetch
# freebsd-update install

Restart all daemons that use the library, or reboot the system.

3) To update your vulnerable system via a source code patch:

The following patches have been verified to apply to the applicable
FreeBSD release branches.

a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.

[FreeBSD 10.x]
# fetch https://security.FreeBSD.org/patches/SA-16:17/openssl-10.patch
# fetch https://security.FreeBSD.org/patches/SA-16:17/openssl-10.patch.asc
# gpg --verify openssl-10.patch.asc

[FreeBSD 9.3]
# fetch https://security.FreeBSD.org/patches/SA-16:17/openssl-9.patc
# fetch https://security.FreeBSD.org/patches/SA-16:17/openssl-9.patch.asc
# gpg --verify openssl-9.patch.asc

b) Apply the patch.  Execute the following commands as root:

# cd /usr/src
# patch < /path/to/patch

c) Recompile the operating system using buildworld and installworld as
described in .

Restart all daemons that use the library, or reboot the system.

VI.  Correction details

The following list contains the correction revision numbers for each
affected branch.

Branch/path                                                      Revision
- -------------------------------------------------------------------------
stable/9/                                                         r299053
releng/9.3/                                                       r299068
stable/10/                                                        r298999
releng/10.1/                                                      r299068
releng/10.2/                                                      r299067
releng/10.3/                                                      r299066
- -------------------------------------------------------------------------

To see which files were modified by a particular revision, run the
following command, replacing NNNNNN with the revision number, on a
machine with Subversion installed:

# svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base

Or visit the following URL, replacing NNNNNN with the revision number:



VII. References













The latest revision of this advisory is available at

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXKjuIAAoJEO1n7NZdz2rneZoP/jqsWr9q5MkCel2aZzfmSVhU
8CjzPwm3t48ibZqrkolAak4dbjJGhidUM/S83BvIcCdtKWyoG8D0fzemB7bBIP2L
fqvd1314vuy82CgZlAyJIqzokckUPfyHhTAz9FPZW46f8A+s8znzJcaaD81tt1Xe
qg9JZ61e2DZJ2NdZSJSjOpBl55gZqQq3tIwGYw027GKjiflJSvOG1n/531R4rppI
x0IZpLor7XBWuiC44hPc4yasC4khWzmdaRpqcUoWVEex8g6Il6xByS2o4AgX7kE/
NBZ0mj4IMYZNQW4VUYbnkmLtWXJYYScboBKh4FRljNCG/t5u/YoSfOY8SbS9LT9K
KVj56C6tQRq+/frKbPt26HbqqRTFNVn3FKxJWNQ9CLzsebobXPUYATTN2NVC8gkj
S0A/lT2xnvA2YqB9HfmHOvlHS2LDv8SivJWNK4dCPOwhVm624H4qH/N+VFcwU7zc
ue+BPvDYU/czsyoJDdQoWxTdkreaOY6eLAWkYAh9dEDIkZSOxgsZR7C4th6THXMu
ybIy544elc3bf9vS4tGR552Wi9VntE0B1/LJ2la8l+MnYE6qZL1hbAYpvNyuPWVP
EDPjOc4inaMpV62fuL1UrKH1g1HMmFUnoWhC70iS+cuLeXWFdvwBFyL420Ixkd5H
zvcsfJCrazlcZ6j83Qfd
=PGTh
-----END PGP SIGNATURE-----

- wong chee tat :)

OpenSSL Security Advisory [3rd May 2016]

OpenSSL Security Advisory [3rd May 2016]
========================================

Memory corruption in the ASN.1 encoder (CVE-2016-2108)
======================================================

Severity: High

This issue affected versions of OpenSSL prior to April 2015. The bug
causing the vulnerability was fixed on April 18th 2015, and released
as part of the June 11th 2015 security releases. The security impact
of the bug was not known at the time.

In previous versions of OpenSSL, ASN.1 encoding the value zero
represented as a negative integer can cause a buffer underflow
with an out-of-bounds write in i2c_ASN1_INTEGER. The ASN.1 parser does
not normally create "negative zeroes" when parsing ASN.1 input, and
therefore, an attacker cannot trigger this bug.

However, a second, independent bug revealed that the ASN.1 parser
(specifically, d2i_ASN1_TYPE) can misinterpret a large universal tag
as a negative zero value. Large universal tags are not present in any
common ASN.1 structures (such as X509) but are accepted as part of ANY
structures.

Therefore, if an application deserializes untrusted ASN.1 structures
containing an ANY field, and later reserializes them, an attacker may
be able to trigger an out-of-bounds write. This has been shown to
cause memory corruption that is potentially exploitable with some
malloc implementations.

Applications that parse and re-encode X509 certificates are known to
be vulnerable. Applications that verify RSA signatures on X509
certificates may also be vulnerable; however, only certificates with
valid signatures trigger ASN.1 re-encoding and hence the
bug. Specifically, since OpenSSL's default TLS X509 chain verification
code verifies the certificate chain from root to leaf, TLS handshakes
could only be targeted with valid certificates issued by trusted
Certification Authorities.

OpenSSL 1.0.2 users should upgrade to 1.0.2c
OpenSSL 1.0.1 users should upgrade to 1.0.1o

This vulnerability is a combination of two bugs, neither of which
individually has security impact. The first bug (mishandling of
negative zero integers) was reported to OpenSSL by Huzaifa Sidhpurwala
(Red Hat) and independently by Hanno Böck in April 2015. The second
issue (mishandling of large universal tags) was found using libFuzzer,
and reported on the public issue tracker on March 1st 2016. The fact
that these two issues combined present a security vulnerability was
reported by David Benjamin (Google) on March 31st 2016. The fixes were
developed by Steve Henson of the OpenSSL development team, and David
Benjamin. The OpenSSL team would also like to thank Mark Brand and
Ian Beer from the Google Project Zero team for their careful analysis
of the impact.

The fix for the "negative zero" memory corruption bug can be
identified by commits

3661bb4e7934668bd99ca777ea8b30eedfafa871 (1.0.2)
and
32d3b0f52f77ce86d53f38685336668d47c5bdfe (1.0.1)

Padding oracle in AES-NI CBC MAC check (CVE-2016-2107)
======================================================

Severity: High

A MITM attacker can use a padding oracle attack to decrypt traffic
when the connection uses an AES CBC cipher and the server support
AES-NI.

This issue was introduced as part of the fix for Lucky 13 padding
attack (CVE-2013-0169). The padding check was rewritten to be in
constant time by making sure that always the same bytes are read and
compared against either the MAC or padding bytes. But it no longer
checked that there was enough data to have both the MAC and padding
bytes.

OpenSSL 1.0.2 users should upgrade to 1.0.2h
OpenSSL 1.0.1 users should upgrade to 1.0.1t

This issue was reported to OpenSSL on 13th of April 2016 by Juraj
Somorovsky using TLS-Attacker. The fix was developed by Kurt Roeckx
of the OpenSSL development team.

EVP_EncodeUpdate overflow (CVE-2016-2105)
=========================================

Severity: Low

An overflow can occur in the EVP_EncodeUpdate() function which is used for
Base64 encoding of binary data. If an attacker is able to supply very large
amounts of input data then a length check can overflow resulting in a heap
corruption.

Internally to OpenSSL the EVP_EncodeUpdate() function is primarly used by the
PEM_write_bio* family of functions. These are mainly used within the OpenSSL
command line applications. These internal uses are not considered vulnerable
because all calls are bounded with length checks so no overflow is possible.
User applications that call these APIs directly with large amounts of untrusted
data may be vulnerable. (Note: Initial analysis suggested that the
PEM_write_bio* were vulnerable, and this is reflected in the patch commit
message. This is no longer believed to be the case).

OpenSSL 1.0.2 users should upgrade to 1.0.2h
OpenSSL 1.0.1 users should upgrade to 1.0.1t

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

EVP_EncryptUpdate overflow (CVE-2016-2106)
==========================================

Severity: Low

An overflow can occur in the EVP_EncryptUpdate() function. If an attacker is
able to supply very large amounts of input data after a previous call to
EVP_EncryptUpdate() with a partial block then a length check can overflow
resulting in a heap corruption. Following an analysis of all OpenSSL internal
usage of the EVP_EncryptUpdate() function all usage is one of two forms.
The first form is where the EVP_EncryptUpdate() call is known to be the first
called function after an EVP_EncryptInit(), and therefore that specific call
must be safe. The second form is where the length passed to EVP_EncryptUpdate()
can be seen from the code to be some small value and therefore there is no
possibility of an overflow. Since all instances are one of these two forms, it
is believed that there can be no overflows in internal code due to this problem.
It should be noted that EVP_DecryptUpdate() can call EVP_EncryptUpdate() in
certain code paths. Also EVP_CipherUpdate() is a synonym for
EVP_EncryptUpdate(). All instances of these calls have also been analysed too
and it is believed there are no instances in internal usage where an overflow
could occur.

This could still represent a security issue for end user code that calls this
function directly.

OpenSSL 1.0.2 users should upgrade to 1.0.2h
OpenSSL 1.0.1 users should upgrade to 1.0.1t

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

ASN.1 BIO excessive memory allocation (CVE-2016-2109)
=====================================================

Severity: Low

When ASN.1 data is read from a BIO using functions such as d2i_CMS_bio()
a short invalid encoding can casuse allocation of large amounts of memory
potentially consuming excessive resources or exhausting memory.

Any application parsing untrusted data through d2i BIO functions is affected.
The memory based functions such as d2i_X509() are *not* affected. Since the
memory based functions are used by the TLS library, TLS applications are not
affected.

OpenSSL 1.0.2 users should upgrade to 1.0.2h
OpenSSL 1.0.1 users should upgrade to 1.0.1t

This issue was reported to OpenSSL on 4th April 2016 by Brian Carpenter.
The fix was developed by Stephen Henson of the OpenSSL development team.

EBCDIC overread (CVE-2016-2176)
===============================

Severity: Low

ASN1 Strings that are over 1024 bytes can cause an overread in applications
using the X509_NAME_oneline() function on EBCDIC systems. This could result in
arbitrary stack data being returned in the buffer.

OpenSSL 1.0.2 users should upgrade to 1.0.2h
OpenSSL 1.0.1 users should upgrade to 1.0.1t

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

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/20160503.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



- wong chee tat :)

OpenSSL Security Advisory [07 Apr 2014]

OpenSSL Security Advisory [07 Apr 2014]
========================================

TLS heartbeat read overrun (CVE-2014-0160)
==========================================

A missing bounds check in the handling of the TLS heartbeat extension can be
used to reveal up to 64k of memory to a connected client or server.

Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including
1.0.1f and 1.0.2-beta1.

Thanks for Neel Mehta of Google Security for discovering this bug and to
Adam Langley  and Bodo Moeller  for
preparing the fix.

Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately
upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS.

1.0.2 will be fixed in 1.0.2-beta2.

- wong chee tat :)