Arch Linux Security Advisory ASA-201611-9

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

Summary

The package libcurl-gnutls 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 “libcurl-gnutls>=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-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-8622 (arbitrary code execution)

The URL percent-encoding decode function in libcurl is called
curl_easy_unescape. Internally, even if this function would be made to
allocate a unscape destination buffer larger than 2GB, it would return
that new length in a signed 32 bit integer variable, thus the length
would get either just truncated or both truncated and turned negative.
That could then lead to libcurl writing outside of its heap based
buffer.

This can be triggered by a user on a 64bit system if the user can send
in a custom (very large) URL to a libcurl using program.

• 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 straße.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_20161102E.html
https://curl.haxx.se/docs/adv_20161102G.html
https://curl.haxx.se/docs/adv_20161102H.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-8619
https://access.redhat.com/security/cve/CVE-2016-8621
https://access.redhat.com/security/cve/CVE-2016-8622
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