Advisories ยป MGASA-2017-0281

Updated curl packages fix security vulnerabilities

Publication date: 19 Aug 2017
Type: security
Affected Mageia releases : 6
CVE: CVE-2017-1000099 , CVE-2017-1000100 , CVE-2017-1000101


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

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