[manjaro-security] [arch-security] [ASA-201710-5] libcurl-gnutls: multiple issues

[Levente Polyak]

Arch Linux Security Advisory ASA-201710-5
=========================================

Severity: Medium
Date    : 2017-10-05
CVE-ID  : CVE-2017-1000099 CVE-2017-1000100 CVE-2017-1000254
Package : libcurl-gnutls
Type    : multiple issues
Remote  : Yes
Link    : https://security.archlinux.org/AVG-387

Summary
=======

The package libcurl-gnutls before version 7.56.0-1 is vulnerable to
multiple issues including information disclosure and denial of service.

Resolution
==========

Upgrade to 7.56.0-1.

# pacman -Syu "libcurl-gnutls>=7.56.0-1"

The problems have been fixed upstream in version 7.56.0.

Workaround
==========

None.

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

- CVE-2017-1000099 (information disclosure)

An information disclosure issue has been found in curl < 7.55.0. When
asking to get a file from a file:// URL, libcurl provides a feature
that outputs meta-data about the file using HTTP-like headers. The code
doing this would send the wrong buffer to the user (stdout or the
application's provide callback), which could lead to other private data
from the heap to get inadvertently displayed. The wrong buffer was an
uninitialized memory area allocated on the heap and if it turned out to
not contain any zero byte, it would continue and display the data
following that buffer in memory.

- CVE-2017-1000100 (information disclosure)

An information disclosure issue has been found in curl < 7.55.0. When
doing a TFTP transfer and curl/libcurl is given a URL that contains a
very long file name (longer than about 515 bytes), the file name is
truncated to fit within the buffer boundaries, but the buffer size is
still wrongly updated to use the untruncated length. This too large
value is then used in the sendto() call, making curl attempt to send
more data than what is actually put into the buffer. The sendto()
function will then read beyond the end of the heap based buffer.
A malicious HTTP(S) server could redirect a vulnerable libcurl-using
client to a crafted TFTP URL (if the client hasn't restricted which
protocols it allows redirects to) and trick it to send private memory
contents to a remote server over UDP.

- CVE-2017-1000254 (denial of service)

When libcurl connects to an FTP server and successfully logs in
(anonymous or not), it asks the server for the current directory with
the `PWD` command. The server then responds with a 257 response
containing the path, inside double quotes. The returned path name is
then kept by libcurl for subsequent uses. Due to a flaw in the string
parser for this directory name, a directory name passed like this but
without a closing double quote would lead to libcurl not adding a
trailing NUL byte to the buffer holding the name. When libcurl would
then later access the string, it could read beyond the allocated heap
buffer and crash or wrongly access data beyond the buffer, thinking it
was part of the path. A malicious server could abuse this fact and
effectively prevent libcurl-based clients to work with it - the PWD
command is always issued on new FTP connections and the mistake has a
high chance of causing a segfault.

Impact
======

An attacker is able to read sensitive information by asking curl to
retrieve a maliciously crafted URL. Furthermore a malicious server can
cause libcurl to segfault when connecting via FTP leading to denial of
service.

References
==========

https://curl.haxx.se/docs/adv_20170809C.html
https://curl.haxx.se/CVE-2017-1000099.patch
https://curl.haxx.se/docs/adv_20170809B.html
https://curl.haxx.se/CVE-2017-1000100.patch
https://curl.haxx.se/docs/adv_20171004.html
https://curl.haxx.se/CVE-2017-1000254.patch
https://github.com/curl/curl/commit/5ff2c5ff25750aba1a8f64fbcad8e5b891512584
https://security.archlinux.org/CVE-2017-1000099
https://security.archlinux.org/CVE-2017-1000100
https://security.archlinux.org/CVE-2017-1000254

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 866 bytes
Desc: OpenPGP digital signature
URL: <http://lists.manjaro.org/pipermail/manjaro-security/attachments/20171006/739a05ce/attachment-0001.sig>