MGASA-2015-0263: curl Mageia

CVSS: UnknownPublished

Published 05-07-2015Last modified 16-04-2026

Open JSON

Vulnerability summary

MGASA-2015-0263 is a vulnerability in curl Mageia with no CVSS score yet.

Overall risk

0/100

0100

Minimal · default modelHow is this calculated?

CVSS score

Not scored

010

No CVSS score recorded

EPSS score

Not scored

0%100%

No EPSS score yet

KEVNot listedIn no KEV catalog

RansomwareNone recordedNo known use recorded

Public exploits0No public exploits recorded

Advisory lineage

Upstream 2 · Downstream 0

CVE-2015-3236 CVE-2015-3237

Timeline

05-07-2015
PublishedVulnerability first disclosed.
16-04-2026
Last modifiedVulnerability information updated.

Description

Updated curl package fixes security vulnerability libcurl can wrongly send HTTP credentials when re-using connections. Even if the handle for an HTTP connection is reset, it retains the credentials, which can cause them to be unintentionally leaked in subsequent requests (CVE-2015-3236). libcurl can get tricked by a malicious SMB server to send off data it did not intend to. A malicious SMB server can use this to access arbitrary process memory, or to crash the client, causing a denial of service (CVE-2015-3237).

CVSS metrics

Risk metrics not yet published.

EPSS trend

No EPSS score has been published for this record yet.

Known exploited

Compare KEV catalogs

Not in any of the 3 tracked catalogs.

Public exploits

0 found

No public exploits indexed.

Weaknesses

CWE · root cause

No weakness data has been published for this record.

Affected systems

Mageia1 product

curl< 7.40.0-3.1.mga5

1 vendor · 1 product

References

4 links

Related vulnerabilities

MGASA-2018-0053mageiacurl8y ago03-01-2018 16:40Updated curl packages fix security vulnerability 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 (CVE-2016-8620). The curl_getdate date parser function would parse either a string with HH:MM or HH:MM:SS. 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-8621). 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-8622). 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 funcion 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 and lead to information disclosure. Another thread can also replace the contents of the cookies from separate HTTP responses or API calls (CVE-2016-8623). 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 (CVE-2016-8624). libcurl's implementation of the printf() functions triggers a buffer overflow when doing a large floating point output. The bug occurs when the conversion outputs more than 255 bytes. The flaw happens because the floating point conversion is using system functions without the correct boundary checks (CVE-2016-9586). There were two bugs in curl's parser for the command line option --write-out (or -w for short) that would skip the end of string zero byte if the string ended in a % (percent) or \ (backslash), and it would read beyond that buffer in the heap memory and it could then potentially output pieces of that memory to the terminal or the target file etc (CVE-2017-7407). 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. Limit curl's redirect protocols with --proto-redir and libcurl's with CURLOPT_REDIR_PROTOCOLS (CVE-2017-1000100). curl supports "globbing" of URLs, in which a user can pass a numerical range to have the tool iterate over those numbers to do a sequence of transfers. In the globbing function that parses the numerical range, there was an omission that made curl read a byte beyond the end of the URL if given a carefully crafted, or just wrongly written, URL. The URL is stored in a heap based buffer, so it could then be made to wrongly read something else instead of crashing (CVE-2017-1000101). 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).MGASA-2016-0285mageiacurl10y ago31-08-2016 15:32Updated curl packages fix security vulnerability libcurl before 7.50.1 would attempt to resume a TLS session even if the client certificate had changed. That is unacceptable since a server by specification is allowed to skip the client certificate check on resume, and may instead use the old identity which was established by the previous certificate (or no certificate) (CVE-2016-5419). In libcurl before 7.50.1, when using a client certificate for a connection that was then put into the connection pool, that connection could then wrongly get reused in a subsequent request to that same server. This mistakenly using the wrong connection could lead to applications sending requests to the wrong realms of the server using authentication that it wasn't supposed to have for those operations (CVE-2016-5420). libcurl before 7.50.1 is vulnerable to a use-after-free flaw in curl_easy_perform() (CVE-2016-5421).CVE-2016-0755canonicalubuntu_linux+229.08%10y ago29-01-2016 20:00The ConnectionExists function in lib/url.c in libcurl before 7.47.0 does not properly re-use NTLM-authenticated proxy connections, which might allow remote attackers to authenticate as other users via a request, a similar issue to CVE-2014-0015.CVE-2016-7167alpinecurl+911.74%10y ago07-10-2016 14:00Multiple integer overflows in the (1) curl_escape, (2) curl_easy_escape, (3) curl_unescape, and (4) curl_easy_unescape functions in libcurl before 7.50.3 allow attackers to have unspecified impact via a string of length 0xffffffff, which triggers a heap-based buffer overflow.