CVE-2017-1000257

An IMAP FETCH response line indicates the size of the returned data, in number of bytes. When that response says the data is zero bytes, libcurl would pass on that (non-existing) data with a pointer and the size (zero) to the deliver-data function. libcurl's deliver-data function treats zero as a magic number and invokes strlen() on the data to figure out the length. The strlen() is called on a heap based buffer that might not be zero terminated so libcurl might read beyond the end of it into whatever memory lies after (or just crash) and then deliver that to the application as if it was actually downloaded.

An IMAP FETCH response line indicates the size of the returned data, in number of bytes. When that response says the data is zero bytes, libcurl would pass on that (non-existing) data with a pointer and the size (zero) to the deliver-data function. libcurl's deliver-data function treats zero as a magic number and invokes strlen() on the data to figure out the length. The strlen() is called on a heap based buffer that might not be zero terminated so libcurl might read beyond the end of it into whatever memory lies after (or just crash) and then deliver that to the application as if it was actually downloaded.

An IMAP FETCH response line indicates the size of the returned data, in number of bytes. When that response says the data is zero bytes, libcurl would pass on that (non-existing) data with a pointer and the size (zero) to the deliver-data function. libcurl's deliver-data function treats zero as a magic number and invokes strlen() on the data to figure out the length. The strlen() is called on a heap based buffer that might not be zero terminated so libcurl might read beyond the end of it into whatever memory lies after (or just crash) and then deliver that to the application as if it was actually downloaded.

libcurl contains a buffer overrun flaw in the IMAP handler.

An IMAP FETCH response line indicates the size of the returned data, in number of bytes. When that response says the data is zero bytes, libcurl would pass on that (non-existing) data with a pointer and the size (zero) to the deliver-data function.

libcurl's deliver-data function treats zero as a magic number and invokes strlen() on the data to figure out the length. The strlen() is called on a heap based buffer that might not be null-terminated so libcurl might read beyond the end of it into whatever memory lies after (or crash) and then deliver that to the application as if it was actually downloaded.

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

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

In libcurl's base64 encode function, the output buffer is allocated without any checks on a variable used to determine its size. On systems with 32-bit addresses in userspace, the multiplication in the expression wraps around if the size is too large. 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-8617).

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 internallty 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. Systems with 64 bit versions of the size_t type are not affected by this issue. This behavior is triggable using the publicly exposed function (CVE-2016-8618).

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

The curl tool's "globbing" feature allows a user to specify a numerical range through which curl will iterate. The curl code for parsing the second unsigned number did not check for a leading minus character, which allowed a user to specify [1--1] with no complaints and have the latter -1 number get turned into the largest unsigned long value the system can handle. This would ultimately cause curl to write outside the dedicated malloced buffer after no less than 100,000 iterations, since it would have room for 5 digits but not 6. When the range is specified with letters, and the ending letter is left out [L-], the code would still advance its read pointer 5 bytes even if the string was just 4 bytes and end up reading outside the given buffer. This flaw exists only in the curl tool, not in the libcurl library…

libcurl contains a buffer overrun flaw in the NTLM authentication code (CVE-2017-8816).

libcurl contains a read out of bounds flaw in the FTP wildcard function (CVE-2017-8817).

libcurl may read outside of a heap allocated buffer when doing FTP (CVE-2017-1000254).

libcurl contains a buffer overrun flaw in the IMAP handler (CVE-2017-1000257).

These are all security issues fixed in the curl-7.79.1-1.1 package on the GA media of openSUSE Tumbleweed.

This update for curl fixes the following issues:

Security issues fixed:

• CVE-2017-1000254: FTP PWD response parser out of bounds read (bsc#1061876)
• CVE-2017-1000257: IMAP FETCH response out of bounds read (bsc#1063824)

Bugs fixed:

• Fixed error 'error:1408F10B:SSL routines' when connecting to ftps via proxy (bsc#1060653)

Brian Carpenter discovered that curl incorrectly handled IMAP FETCH response lines. A remote attacker could use this issue to cause curl to crash, resulting in a denial of service, or possibly execute arbitrary code.