[arch-security] [ASA-201605-4] lib32-openssl: multiple issues

[Remi Gacogne]

Arch Linux Security Advisory ASA-201605-4
=========================================

Severity: High
Date    : 2016-05-04
CVE-ID  : CVE-2016-2105 CVE-2016-2106 CVE-2016-2107 CVE-2016-2109
          CVE-2016-2176
Package : lib32-openssl
Type    : multiple issues
Remote  : Yes
Link    : https://wiki.archlinux.org/index.php/CVE

Summary
=======

The package lib32-openssl before version 1:1.0.2.h-1 is vulnerable to
multiple issues leading to man-in-the-middle or possibly arbitrary code
execution.

Resolution
==========

Upgrade to 1:1.0.2.h-1.

# pacman -Syu "lib32-openssl>=1:1.0.2.h-1"

The problem has been fixed upstream in version 1.0.2h.

Workaround
==========

None.

Description
===========

- CVE-2016-2105 (buffer overflow):

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 primarily 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).

- CVE-2016-2106 (buffer overflow):

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.

- CVE-2016-2107 (man-in-the-middle):

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.

- CVE-2016-2109 (memory exhaustion):

When ASN.1 data is read from a BIO using functions such as d2i_CMS_bio()
a short invalid encoding can cause 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.

- CVE-2016-2176 (information leak):

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.

Impact
======

A remote attacker might be able to do a man-in-the-middle attack, access
sensitive information, cause a crash or execute arbitrary code on the
affected host.

References
==========

https://www.openssl.org/news/secadv/20160503.txt
https://access.redhat.com/security/cve/CVE-2016-2105
https://access.redhat.com/security/cve/CVE-2016-2106
https://access.redhat.com/security/cve/CVE-2016-2107
https://access.redhat.com/security/cve/CVE-2016-2109
https://access.redhat.com/security/cve/CVE-2016-2176

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-security/attachments/20160504/317d002a/attachment.asc>