[arch-security] [ASA-201611-4] lib32-curl: multiple issues

Wed Nov 2 17:35:48 UTC 2016

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

Severity: High
Date    : 2016-11-02
CVE-ID  : CVE-2016-8615 CVE-2016-8616 CVE-2016-8617 CVE-2016-8618
          CVE-2016-8619 CVE-2016-8621 CVE-2016-8623 CVE-2016-8624
          CVE-2016-8625
Package : lib32-curl
Type    : multiple issues
Remote  : Yes
Link    : https://wiki.archlinux.org/index.php/CVE

Summary
=======

The package lib32-curl before version 7.51.0-1 is vulnerable to
multiple issues including arbitrary code execution, content spoofing,
information disclosure, insufficient validation and authentication
bypass.

Resolution
==========

Upgrade to 7.51.0-1.

# pacman -Syu "lib32-curl>=7.51.0-1"

The problems have been fixed upstream in version 7.51.0.

Workaround
==========

None.

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

- CVE-2016-8615 (content spoofing)

If cookie state is written into a cookie jar file that is later read
back and used for subsequent requests, a malicious HTTP server can
inject new cookies for arbitrary domains into said cookie jar.

The issue pertains to the function that loads cookies into memory,
which reads the specified file into a fixed-size buffer in a line-by-
line manner using the fgets() function. If an invocation of fgets()
cannot read the whole line into the destination buffer due to it being
too small, it truncates the output. This way, a very long cookie (name
+ value) sent by a malicious server would be stored in the file and
subsequently that cookie could be read partially and crafted correctly,
it could be treated as a different cookie for another server.

- CVE-2016-8616 (authentication bypass)

When re-using a connection, curl was doing case insensitive comparisons
of user name and password with the existing connections.

This means that if an unused connection with proper credentials exists
for a protocol that has connection-scoped credentials, an attacker can
cause that connection to be reused if s/he knows the case-insensitive
version of the correct password.

- CVE-2016-8617 (arbitrary code execution)

In libcurl's base64 encode function, the output buffer is allocated as
follows without any checks on insize:

malloc( insize * 4 / 3 + 4 )
On systems with 32-bit addresses in userspace (e.g. x86, ARM, x32), the
multiplication in the expression wraps around if insize is at least 1GB
of data. If this happens, an undersized output buffer will be
allocated, but the full result will be written, thus causing the memory
behind the output buffer to be overwritten.

If a username is set directly via CURLOPT_USERNAME (or curl's -u,
--user option), this vulnerability can be triggered. The name has to be
at least 512MB big in a 32bit system.

Systems with 64 bit versions of the size_t type are not affected by
this issue.

- CVE-2016-8618 (arbitrary code execution)

The libcurl API function called curl_maprintf() can be tricked into
doing a double-free due to an unsafe size_t multiplication, on systems
using 32 bit size_t variables. The function is also used internally in
numerous situations.

The function doubles an allocated memory area with realloc() and allows
the size to wrap and become zero and when doing so realloc() returns
NULL and frees the memory - in contrary to normal realloc() fails where
it only returns NULL - causing libcurl to free the memory again in the
error path.

This behavior is triggerable using the publicly exposed function.
Systems with 64 bit versions of the size_t type are not affected by
this issue.

- CVE-2016-8619 (arbitrary code execution)

In curl's implementation of the Kerberos authentication mechanism, the
function read_data() in security.c is used to fill the necessary krb5
structures. When reading one of the length fields from the socket, it
fails to ensure that the length parameter passed to realloc() is not
set to 0.

This would lead to realloc() getting called with a zero size and when
doing so realloc() returns NULL and frees the memory - in contrary to
normal realloc() fails where it only returns NULL - causing libcurl to
free the memory again in the error path.

This flaw could be triggered by a malicious or just otherwise ill-
behaving server.

- CVE-2016-8621 (information disclosure)

The curl_getdate converts a given date string into a numerical
timestamp and it supports a range of different formats and possibilites
to express a date and time. The underlying date parsing function is
also used internally when parsing for example HTTP cookies (possibly
received from remote servers) and it can be used when doing conditional
HTTP requests.

The date parser function uses the libc sscanf() function at two places,
with the parsing strings "%02d:%02d" and ""%02d:%02d:%02d". The intent
being that it would parse either a string with HH:MM (two digits colon
two digits) or HH:MM:SS (two digits colon two digits colon two digits).
If instead the piece of time that was sent in had the final digit cut
off, thus ending with a single-digit, the date parser code would
advance its read pointer one byte too much and end up reading out of
bounds.

- CVE-2016-8623 (arbitrary code execution)

libcurl explicitly allows users to share cookies between multiple easy
handles that are concurrently employed by different threads.
When cookies to be sent to a server are collected, the matching
function collects all cookies to send and the cookie lock is released
immediately afterwards. That function however only returns a list with
references back to the original strings for name, value, path and so
on. Therefore, if another thread quickly takes the lock and frees one
of the original cookie structs together with its strings, a use-after-
free can occur possibly leading to arbitrary code execution. Another
thread can also replace the contents of the cookies from separate HTTP
responses or API calls.

- CVE-2016-8624 (insufficient validation)

curl doesn't parse the authority component of the URL correctly when
the host name part ends with a '#' character, and could instead be
tricked into connecting to a different host. This may have security
implications if you for example use a URL parser that follows the RFC
to check for allowed domains before using curl to request them.

Passing in http://example.com#@evil.com/x.txt would wrongly make curl
send a request to evil.com while your browser would connect to
example.com given the same URL.

The problem exists for most protocol schemes.

- CVE-2016-8625 (insufficient validation)

When curl is built with libidn to handle International Domain Names
(IDNA), it translates them to puny code for DNS resolving using the
IDNA 2003 standard, while IDNA 2008 is the modern and up-to-date IDNA
standard. This misalignment causes problems with for example domains
using the German ß character (known as the Unicode Character 'LATIN
SMALL LETTER SHARP S') which is used at times in the .de TLD and is
translated differently in the two IDNA standards, leading to users
potentially and unknowingly issuing network transfer requests to the
wrong host.

For example, straße.de is translated into strasse.de using IDNA 2003
but is translated into xn--strae-oqa.de using IDNA 2008. Needless to
say, those host names could very well resolve to different addresses
and be two completely independent servers. IDNA 2008 is mandatory for
.de domains.

This name problem exists for DNS-using protocols in curl, but only when
built to use libidn.

Impact
======

A remote attacker is able to execute arbitrary code, inject cookies for
arbitrary domains and disclose sensitive information via various vectors.

References
==========

https://curl.haxx.se/changes.html#7_51_0
https://curl.haxx.se/docs/adv_20161102A.html
https://curl.haxx.se/docs/adv_20161102B.html
https://curl.haxx.se/docs/adv_20161102C.html
https://curl.haxx.se/docs/adv_20161102D.html
https://curl.haxx.se/docs/adv_20161102E.html
https://curl.haxx.se/docs/adv_20161102G.html
https://curl.haxx.se/docs/adv_20161102I.html
https://curl.haxx.se/docs/adv_20161102J.html
https://curl.haxx.se/docs/adv_20161102K.html
https://access.redhat.com/security/cve/CVE-2016-8615
https://access.redhat.com/security/cve/CVE-2016-8616
https://access.redhat.com/security/cve/CVE-2016-8617
https://access.redhat.com/security/cve/CVE-2016-8618
https://access.redhat.com/security/cve/CVE-2016-8619
https://access.redhat.com/security/cve/CVE-2016-8621
https://access.redhat.com/security/cve/CVE-2016-8623
https://access.redhat.com/security/cve/CVE-2016-8624
https://access.redhat.com/security/cve/CVE-2016-8625

-------------- 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/20161102/28e8e44d/attachment.asc>