Bug 19700 - curl new security issues CVE-2016-861[5-9], CVE-2016-862[0-4], CVE-2016-9586, and CVE-2017-7407
Summary: curl new security issues CVE-2016-861[5-9], CVE-2016-862[0-4], CVE-2016-9586,...
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 5
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
URL: http://lwn.net/Vulnerabilities/705367/
Whiteboard: MGA5-32-OK MGA6-64-OK
Keywords: Triaged, advisory, has_procedure, validated_update
Depends on: 21481 21819
Blocks:
  Show dependency treegraph
 
Reported: 2016-11-02 18:42 CET by David Walser
Modified: 2018-01-03 17:41 CET (History)
10 users (show)

See Also:
Source RPM: curl-7.40.0-3.5.mga5.src.rpm
CVE:
Status comment:


Attachments

Description David Walser 2016-11-02 18:42:18 CET
cURL has issued advisories today (November 2):
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_20161102D.html
https://curl.haxx.se/docs/adv_20161102E.html
https://curl.haxx.se/docs/adv_20161102F.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

The last of those, CVE-2016-8625, has generated some discussion on oss-security:
http://openwall.com/lists/oss-security/2016/11/02/13

We don't have libidn2 packaged, and I had previously disabled libidn support to mitigate CVE-2015-2059, so we should just continue to leave that disabled and we shouldn't be affected by CVE-2016-8625.

The issues are fixed in 7.51.0:
https://curl.haxx.se/changes.html

Freeze push requested for Cauldron.

We'll need to add the patches for Mageia 5.
Comment 1 Marja Van Waes 2016-11-03 09:10:01 CET
Assigning to the registered maintainer.

Keywords: (none) => Triaged
CC: (none) => marja11
Assignee: bugsquad => shlomif

Comment 2 Shlomi Fish 2016-11-03 12:33:53 CET
Thanks for the headsup - I applied the modified patches locally and submitted the new curl to mgav5 core updates_testing. Hopefully it will build fine there.
Comment 3 Nicolas Lécureuil 2016-11-16 17:52:07 CET
SRPMS: curl-7.40.0-3.6.mga5

CC: (none) => mageia
Assignee: shlomif => qa-bugs

Comment 4 Nicolas Lécureuil 2016-11-16 18:08:11 CET
it does not build, can you take a look and fix please ?
David Walser 2016-11-16 19:11:52 CET

Assignee: qa-bugs => shlomif

Comment 5 David Walser 2016-12-21 23:58:19 CET
Upstream has issued an advisory today (December 21):
https://curl.haxx.se/docs/adv_20161221A.html

Freeze push requested for Cauldron.

Rediffed patch checked into Mageia 5 SVN, but the mess from the previous security issues hasn't been cleaned up yet, so we can't build this.

Summary: curl new security issues CVE-2016-861[5-9] and CVE-2016-862[0-4] => curl new security issues CVE-2016-861[5-9], CVE-2016-862[0-4], and CVE-2016-9586

Comment 6 David Walser 2016-12-28 18:42:00 CET
LWN reference for CVE-2016-9586:
https://lwn.net/Vulnerabilities/710279/
Comment 7 David Walser 2017-04-05 11:58:26 CEST
Upstream has issued an advisory on April 3:
https://curl.haxx.se/docs/adv_20170403.html

Patch checked into Cauldron SVN, but it needs rediffed for Mageia 5.

Summary: curl new security issues CVE-2016-861[5-9], CVE-2016-862[0-4], and CVE-2016-9586 => curl new security issues CVE-2016-861[5-9], CVE-2016-862[0-4], CVE-2016-9586, and CVE-2017-7407

Comment 8 David Walser 2017-04-10 10:22:30 CEST
(In reply to David Walser from comment #7)
> Upstream has issued an advisory on April 3:
> https://curl.haxx.se/docs/adv_20170403.html
> 
> Patch checked into Cauldron SVN, but it needs rediffed for Mageia 5.

Fedora has issued an advisory for this on April 9:
https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/OIYGCVQARXZJTLMUA6GQQ6AJ56TDXEDA/
David Walser 2017-08-10 01:11:16 CEST

Depends on: (none) => 21481

Comment 9 David Walser 2017-08-10 18:51:55 CEST
Update built, advisory to come.  Updated packages listed below.

curl-7.40.0-3.10.mga5
libcurl4-7.40.0-3.10.mga5
libcurl-devel-7.40.0-3.10.mga5
curl-examples-7.40.0-3.10.mga5

from curl-7.40.0-3.10.mga5.src.rpm

Assignee: shlomif => qa-bugs

Comment 10 David Walser 2017-08-10 19:20:00 CEST
Testing procedure:
https://bugs.mageia.org/show_bug.cgi?id=14468#c4

Advisory:
========================

Updated curl packages fix security vulnerabilities:

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

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8615
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8616
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8617
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8618
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8619
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8620
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8621
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8622
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8623
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8624
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-9586
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7407
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000100
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000101
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_20161102D.html
https://curl.haxx.se/docs/adv_20161102E.html
https://curl.haxx.se/docs/adv_20161102F.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_20161221A.html
https://curl.haxx.se/docs/adv_20170403.html
https://curl.haxx.se/docs/adv_20170809A.html
https://curl.haxx.se/docs/adv_20170809B.html

Whiteboard: (none) => has_procedure

Comment 11 PC LX 2017-08-10 19:24:33 CEST
Installed without issue but it is NOT working. A simple test failed.


$ uname -a
Linux marte 4.4.79-desktop-1.mga5 #1 SMP Fri Jul 28 02:50:06 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
$
$ rpm -qa | grep curl.*7.40
lib64curl4-7.40.0-3.8.mga5
libcurl4-7.40.0-3.8.mga5
curl-7.40.0-3.8.mga5
$
$
$
$ curl -vv http://example.com/
* Rebuilt URL to: http://ex/example.com
* getaddrinfo(3) failed for //:80
* Couldn't resolve host '//'
* Closing connection 0
curl: (6) Couldn't resolve host '//'
$
$
$
$ curl -vv http://example.com:80/
* Rebuilt URL to: http://ex/example.com:80
* getaddrinfo(3) failed for //:80
* Couldn't resolve host '//'
* Closing connection 0
curl: (6) Couldn't resolve host '//'
*** Error in `curl': corrupted double-linked list: 0x0000000001021c00 ***
^C
$
$
$ # Curiously, it works without http://.
$ curl -Ivv example.com
* Rebuilt URL to: example.com/
*   Trying 93.184.216.34...
* Connected to example.com (93.184.216.34) port 80 (#0)
> HEAD / HTTP/1.1
> User-Agent: curl/7.40.0
> Host: example.com
> Accept: */*
> 
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Accept-Ranges: bytes
Accept-Ranges: bytes
< Cache-Control: max-age=604800
Cache-Control: max-age=604800
< Content-Type: text/html
Content-Type: text/html
< Date: Thu, 10 Aug 2017 17:18:29 GMT
Date: Thu, 10 Aug 2017 17:18:29 GMT
< Etag: "359670651+gzip"
Etag: "359670651+gzip"
< Expires: Thu, 17 Aug 2017 17:18:29 GMT
Expires: Thu, 17 Aug 2017 17:18:29 GMT
< Last-Modified: Fri, 09 Aug 2013 23:54:35 GMT
Last-Modified: Fri, 09 Aug 2013 23:54:35 GMT
< Server: ECS (lga/13A4)
Server: ECS (lga/13A4)
< X-Cache: HIT
X-Cache: HIT
< Content-Length: 1270
Content-Length: 1270

< 
* Connection #0 to host example.com left intact
$

CC: (none) => mageia

Comment 12 David Walser 2017-08-10 19:33:33 CEST
I guess we need to fix those failing tests.

Whiteboard: has_procedure => has_procedure feedback

Comment 13 PC LX 2017-08-10 20:01:42 CEST
After installing curl's debuginfo package using:
# debuginfo-install curl-7.40.0-3.8.mga5.x86_64)

And running:
# gdb /usr/bin/curl

I get the following messages:
warning: the debug information found in "/usr/lib/debug/usr/bin/curl.debug" does not match "/usr/bin/curl" (CRC mismatch).
Reading symbols from /usr/bin/curl...(no debugging symbols found)...done.

There is a miss match between the curl binary and the debug info.

Could it be that the binary in the package is corrupted?
Comment 14 PC LX 2017-08-10 20:05:30 CEST
From valgrind's memcheck (see below), it seems there is a buffer overflow by 1 byte.

$ valgrind --tool=memcheck curl -Ivv http://example.com:80/
==31355== Memcheck, a memory error detector
==31355== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==31355== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==31355== Command: curl -Ivv http://example.com:80/
==31355== 
==31355== Invalid write of size 1
==31355==    at 0x4C2C753: memcpy@@GLIBC_2.14 (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==31355==    by 0x4E568CD: ??? (in /usr/lib64/libcurl.so.4.3.0)
==31355==    by 0x4E695A2: ??? (in /usr/lib64/libcurl.so.4.3.0)
==31355==    by 0x4E6A2DC: curl_multi_perform (in /usr/lib64/libcurl.so.4.3.0)
==31355==    by 0x4E612BA: curl_easy_perform (in /usr/lib64/libcurl.so.4.3.0)
==31355==    by 0x40AC00: ??? (in /usr/bin/curl)
==31355==    by 0x40C3BC: ??? (in /usr/bin/curl)
==31355==    by 0x402433: ??? (in /usr/bin/curl)
==31355==    by 0x52E304F: (below main) (in /usr/lib64/libc-2.20.so)
==31355==  Address 0x78509a8 is 0 bytes after a block of size 24 alloc'd
==31355==    at 0x4C27F7F: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==31355==    by 0x4E56892: ??? (in /usr/lib64/libcurl.so.4.3.0)
==31355==    by 0x4E695A2: ??? (in /usr/lib64/libcurl.so.4.3.0)
==31355==    by 0x4E6A2DC: curl_multi_perform (in /usr/lib64/libcurl.so.4.3.0)
==31355==    by 0x4E612BA: curl_easy_perform (in /usr/lib64/libcurl.so.4.3.0)
==31355==    by 0x40AC00: ??? (in /usr/bin/curl)
==31355==    by 0x40C3BC: ??? (in /usr/bin/curl)
==31355==    by 0x402433: ??? (in /usr/bin/curl)
==31355==    by 0x52E304F: (below main) (in /usr/lib64/libc-2.20.so)
==31355== 
==31355== Invalid read of size 1
==31355==    at 0x4C2AF44: strlen (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==31355==    by 0x4E5BA26: ??? (in /usr/lib64/libcurl.so.4.3.0)
==31355==    by 0x4E5BE74: curl_mvsnprintf (in /usr/lib64/libcurl.so.4.3.0)
==31355==    by 0x4E4A51B: ??? (in /usr/lib64/libcurl.so.4.3.0)
==31355==    by 0x4E56928: ??? (in /usr/lib64/libcurl.so.4.3.0)
==31355==    by 0x4E695A2: ??? (in /usr/lib64/libcurl.so.4.3.0)
==31355==    by 0x4E6A2DC: curl_multi_perform (in /usr/lib64/libcurl.so.4.3.0)
==31355==    by 0x4E612BA: curl_easy_perform (in /usr/lib64/libcurl.so.4.3.0)
==31355==    by 0x40AC00: ??? (in /usr/bin/curl)
==31355==    by 0x40C3BC: ??? (in /usr/bin/curl)
==31355==    by 0x402433: ??? (in /usr/bin/curl)
==31355==    by 0x52E304F: (below main) (in /usr/lib64/libc-2.20.so)
==31355==  Address 0x78509a8 is 0 bytes after a block of size 24 alloc'd
==31355==    at 0x4C27F7F: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==31355==    by 0x4E56892: ??? (in /usr/lib64/libcurl.so.4.3.0)
==31355==    by 0x4E695A2: ??? (in /usr/lib64/libcurl.so.4.3.0)
==31355==    by 0x4E6A2DC: curl_multi_perform (in /usr/lib64/libcurl.so.4.3.0)
==31355==    by 0x4E612BA: curl_easy_perform (in /usr/lib64/libcurl.so.4.3.0)
==31355==    by 0x40AC00: ??? (in /usr/bin/curl)
==31355==    by 0x40C3BC: ??? (in /usr/bin/curl)
==31355==    by 0x402433: ??? (in /usr/bin/curl)
==31355==    by 0x52E304F: (below main) (in /usr/lib64/libc-2.20.so)
==31355== 
* Rebuilt URL to: http://ex/example.com:80
* getaddrinfo(3) failed for //:80
* Couldn't resolve host '//'
* Closing connection 0
curl: (6) Couldn't resolve host '//'
==31355== 
==31355== HEAP SUMMARY:
==31355==     in use at exit: 1,647 bytes in 8 blocks
==31355==   total heap usage: 4,442 allocs, 4,434 frees, 378,348 bytes allocated
==31355== 
==31355== LEAK SUMMARY:
==31355==    definitely lost: 0 bytes in 0 blocks
==31355==    indirectly lost: 0 bytes in 0 blocks
==31355==      possibly lost: 0 bytes in 0 blocks
==31355==    still reachable: 1,647 bytes in 8 blocks
==31355==         suppressed: 0 bytes in 0 blocks
==31355== Rerun with --leak-check=full to see details of leaked memory
==31355== 
==31355== For counts of detected and suppressed errors, rerun with: -v
==31355== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
Comment 15 PC LX 2017-08-10 20:18:51 CEST
Installed the update (curl-7.40.0-3.10.mga5) and the issue remains.

The curl-debuginfo now matches the curl binary so I run it in gdb and valgrind again. The backtraces are below.

There seems to be issues in parseurlandfillconn at url.c:4085 and url.c:4093.


$ rpm -qa | grep curl.*7.40 | sort
curl-7.40.0-3.10.mga5
curl-debuginfo-7.40.0-3.10.mga5
lib64curl4-7.40.0-3.10.mga5
libcurl4-7.40.0-3.10.mga5
$
$
$
$ gdb /usr/bin/curl
<...>
(gdb) run -Ivv http://example.com:80/
Starting program: /usr/bin/curl -Ivv http://example.com:80/
Missing separate debuginfos, use: debuginfo-install glibc-2.20-25.mga5.x86_64
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
* Rebuilt URL to: http://ex/example.com:80
* getaddrinfo(3) failed for //:80
* Couldn't resolve host '//'
* Closing connection 0
curl: (6) Couldn't resolve host '//'
*** Error in `/usr/bin/curl': corrupted double-linked list: 0x0000000000648c00 ***
^C
Program received signal SIGINT, Interrupt.
0x00007ffff769ec3b in __lll_lock_wait_private () from /lib64/libc.so.6
(gdb) bt
#0  0x00007ffff769ec3b in __lll_lock_wait_private () from /lib64/libc.so.6
#1  0x00007ffff7617455 in malloc () from /lib64/libc.so.6
#2  0x00007ffff7de5507 in _dl_map_object () from /lib64/ld-linux-x86-64.so.2
#3  0x00007ffff7df03ac in dl_open_worker () from /lib64/ld-linux-x86-64.so.2
#4  0x00007ffff7dec434 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2
#5  0x00007ffff7defe83 in _dl_open () from /lib64/ld-linux-x86-64.so.2
#6  0x00007ffff76cbccd in do_dlopen () from /lib64/libc.so.6
#7  0x00007ffff7dec434 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2
#8  0x00007ffff76cbd84 in __libc_dlopen_mode () from /lib64/libc.so.6
#9  0x00007ffff769f4d5 in init () from /lib64/libc.so.6
#10 0x00007ffff5451ae0 in pthread_once () from /lib64/libpthread.so.0
#11 0x00007ffff769f5ec in backtrace () from /lib64/libc.so.6
#12 0x00007ffff75b9b1a in backtrace_and_maps () from /lib64/libc.so.6
#13 0x00007ffff760c38e in __libc_message () from /lib64/libc.so.6
#14 0x00007ffff7612a6e in malloc_consolidate () from /lib64/libc.so.6
#15 0x00007ffff76143a8 in _int_free () from /lib64/libc.so.6
#16 0x00007ffff7617798 in free () from /lib64/libc.so.6
#17 0x00007ffff7b8aec5 in Curl_close (data=0x648cc0) at url.c:493
#18 0x00007ffff7b963ca in curl_easy_cleanup (curl=0x7ffff7948cc0 <main_arena>) at easy.c:852
#19 0x0000000000402440 in main_free (config=0x7fffffffd9d0) at tool_main.c:206
#20 main (argc=3, argv=0x7fffffffdb38) at tool_main.c:260
(gdb) quit
<...>
$
$
$
$ valgrind curl -Ivv http://example.com:80/
==31826== Memcheck, a memory error detector
==31826== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==31826== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==31826== Command: curl -Ivv http://example.com:80/
==31826== 
==31826== Invalid write of size 1
==31826==    at 0x4C2C753: memcpy@@GLIBC_2.14 (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==31826==    by 0x4E5687D: UnknownInlinedFun (string3.h:51)
==31826==    by 0x4E5687D: parseurlandfillconn (url.c:4085)
==31826==    by 0x4E5687D: create_conn (url.c:5370)
==31826==    by 0x4E5687D: Curl_connect (url.c:5884)
==31826==    by 0x4E69552: multi_runsingle (multi.c:1048)
==31826==    by 0x4E6A28C: curl_multi_perform (multi.c:1802)
==31826==    by 0x4E6126A: easy_transfer (easy.c:717)
==31826==    by 0x4E6126A: easy_perform (easy.c:805)
==31826==    by 0x4E6126A: curl_easy_perform (easy.c:824)
==31826==    by 0x40AC00: operate_do (tool_operate.c:1379)
==31826==    by 0x40C3BC: operate (tool_operate.c:1847)
==31826==    by 0x402433: main (tool_main.c:252)
==31826==  Address 0x78509a8 is 0 bytes after a block of size 24 alloc'd
==31826==    at 0x4C27F7F: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==31826==    by 0x4E56842: parseurlandfillconn (url.c:4077)
==31826==    by 0x4E56842: create_conn (url.c:5370)
==31826==    by 0x4E56842: Curl_connect (url.c:5884)
==31826==    by 0x4E69552: multi_runsingle (multi.c:1048)
==31826==    by 0x4E6A28C: curl_multi_perform (multi.c:1802)
==31826==    by 0x4E6126A: easy_transfer (easy.c:717)
==31826==    by 0x4E6126A: easy_perform (easy.c:805)
==31826==    by 0x4E6126A: curl_easy_perform (easy.c:824)
==31826==    by 0x40AC00: operate_do (tool_operate.c:1379)
==31826==    by 0x40C3BC: operate (tool_operate.c:1847)
==31826==    by 0x402433: main (tool_main.c:252)
==31826== 
==31826== Invalid read of size 1
==31826==    at 0x4C2AF44: strlen (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==31826==    by 0x4E5B9D6: dprintf_formatf (mprintf.c:811)
==31826==    by 0x4E5BE24: curl_mvsnprintf (mprintf.c:992)
==31826==    by 0x4E4A4CB: Curl_infof (sendf.c:135)
==31826==    by 0x4E568D8: parseurlandfillconn (url.c:4093)
==31826==    by 0x4E568D8: create_conn (url.c:5370)
==31826==    by 0x4E568D8: Curl_connect (url.c:5884)
==31826==    by 0x4E69552: multi_runsingle (multi.c:1048)
==31826==    by 0x4E6A28C: curl_multi_perform (multi.c:1802)
==31826==    by 0x4E6126A: easy_transfer (easy.c:717)
==31826==    by 0x4E6126A: easy_perform (easy.c:805)
==31826==    by 0x4E6126A: curl_easy_perform (easy.c:824)
==31826==    by 0x40AC00: operate_do (tool_operate.c:1379)
==31826==    by 0x40C3BC: operate (tool_operate.c:1847)
==31826==    by 0x402433: main (tool_main.c:252)
==31826==  Address 0x78509a8 is 0 bytes after a block of size 24 alloc'd
==31826==    at 0x4C27F7F: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==31826==    by 0x4E56842: parseurlandfillconn (url.c:4077)
==31826==    by 0x4E56842: create_conn (url.c:5370)
==31826==    by 0x4E56842: Curl_connect (url.c:5884)
==31826==    by 0x4E69552: multi_runsingle (multi.c:1048)
==31826==    by 0x4E6A28C: curl_multi_perform (multi.c:1802)
==31826==    by 0x4E6126A: easy_transfer (easy.c:717)
==31826==    by 0x4E6126A: easy_perform (easy.c:805)
==31826==    by 0x4E6126A: curl_easy_perform (easy.c:824)
==31826==    by 0x40AC00: operate_do (tool_operate.c:1379)
==31826==    by 0x40C3BC: operate (tool_operate.c:1847)
==31826==    by 0x402433: main (tool_main.c:252)
==31826== 
* Rebuilt URL to: http://ex/example.com:80
* getaddrinfo(3) failed for //:80
* Couldn't resolve host '//'
* Closing connection 0
curl: (6) Couldn't resolve host '//'
==31826== 
==31826== HEAP SUMMARY:
==31826==     in use at exit: 1,647 bytes in 8 blocks
==31826==   total heap usage: 4,442 allocs, 4,434 frees, 378,348 bytes allocated
==31826== 
==31826== LEAK SUMMARY:
==31826==    definitely lost: 0 bytes in 0 blocks
==31826==    indirectly lost: 0 bytes in 0 blocks
==31826==      possibly lost: 0 bytes in 0 blocks
==31826==    still reachable: 1,647 bytes in 8 blocks
==31826==         suppressed: 0 bytes in 0 blocks
==31826== Rerun with --leak-check=full to see details of leaked memory
==31826== 
==31826== For counts of detected and suppressed errors, rerun with: -v
==31826== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
$
Comment 16 David Walser 2017-08-10 23:00:37 CEST
I wonder if Shlomi can help.  I wanted to CC Dan Fandrich too but Bugzilla can't find him.

CC: (none) => shlomif

Comment 17 Dave Hodgins 2017-08-12 06:31:28 CEST
Also noticed segfaults in boinc. Fixed by running ...
# urpmi --downgrade curl-7.40.0-3.5.mga5 libcurl4-7.40.0-3.5.mga5 lib64curl4-7.40.0-3.5.mga5
The following packages have to be removed for others to be upgraded:
curl-7.40.0-3.10.mga5.x86_64
 (due to unsatisfied lib64curl4 == 1:7.40.0-3.10.mga5)
lib64curl4-7.40.0-3.10.mga5.x86_64
 (in order to install lib64curl4-7.40.0-3.5.mga5.x86_64)
libcurl4-7.40.0-3.10.mga5.i586
 (in order to install libcurl4-7.40.0-3.5.mga5.i586) (y/N

CC: (none) => davidwhodgins

Comment 18 David Walser 2017-08-12 23:41:36 CEST
CC'ing Dan Fandrich.  We have been unable to get a security update for curl out for over 9 months, because of an issue with one of the upstream patches from last November.  Can you help?

CC: (none) => dan

Comment 19 Bjarne Thomsen 2017-08-13 20:58:12 CEST
curl-7.40.0-3.10 in updates-testing gives signal 11 for both i586 and x86_64.
It happened during
urpmi --auto-update
Is this a well known problem?

CC: (none) => bjarne.thomsen

Comment 20 PC LX 2017-08-13 21:13:26 CEST
(In reply to Bjarne Thomsen from comment #19)
> curl-7.40.0-3.10 in updates-testing gives signal 11 for both i586 and x86_64.
> It happened during
> urpmi --auto-update

The curl-7.40.0-3.10 package has a broken curl binary and if urpmi is setup to use curl it will stop working.

To work around this issue, change the downloader used by urpmi to wget or aria2. The downloader can be changed in the file /etc/urpmi/urpmi.cfg or using the drakrpm-edit-media GUI program.

$ head -n 5 /etc/urpmi/urpmi.cfg 
{
  downloader: wget
  verify-rpm: 1
  xml-info: 
}


> Is this a well known problem?

Don't know!
Comment 21 David Walser 2017-08-13 23:38:29 CEST
(In reply to Bjarne Thomsen from comment #19)
> Is this a well known problem?

Yes, it was reported a few comments earlier in this same bug.  Did you intend to test this update?  If not, make sure you don't install packages from updates_testing that you weren't specifically trying to test.
David Walser 2017-08-22 18:52:54 CEST

Assignee: qa-bugs => shlomif
CC: (none) => qa-bugs

Frédéric "LpSolit" Buclin 2017-09-06 16:09:53 CEST

Keywords: (none) => feedback, has_procedure
Whiteboard: has_procedure feedback => (none)

David Walser 2017-10-07 17:48:08 CEST

Depends on: (none) => 21819

Comment 22 Zombie Ryushu 2017-11-29 22:18:35 CET
    CVE-2017-8816

    Alex Nichols discovered a buffer overrun flaw in the NTLM authentication code which can be triggered on 32bit systems where an integer overflow might occur when calculating the size of a memory allocation.
    CVE-2017-8817

    Fuzzing by the OSS-Fuzz project led to the discovery of a read out of bounds flaw in the FTP wildcard function in libcurl. A malicious server could redirect a libcurl-based

CC: (none) => zombie_ryushu

Comment 23 David Walser 2017-11-30 21:17:42 CET
(In reply to Zombie Ryushu from comment #22)
>     CVE-2017-8816
> 
>     Alex Nichols discovered a buffer overrun flaw in the NTLM authentication
> code which can be triggered on 32bit systems where an integer overflow might
> occur when calculating the size of a memory allocation.
>     CVE-2017-8817
> 
>     Fuzzing by the OSS-Fuzz project led to the discovery of a read out of
> bounds flaw in the FTP wildcard function in libcurl. A malicious server
> could redirect a libcurl-based

https://bugs.mageia.org/show_bug.cgi?id=21819#c5

If you're going to keep this up, please give the DSA links instead of pasting the contents.  Do note that I already track Debian's advisories.
Comment 24 Zombie Ryushu 2017-11-30 23:45:41 CET
Very well.
Comment 25 David Walser 2017-12-27 22:04:58 CET
Try it now.

Advisory:
========================

Updated curl packages fix security vulnerabilities:

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

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8615
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8616
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8617
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8618
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8619
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8620
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8621
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8622
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8623
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8624
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-9586
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7407
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-8816
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-8817
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000100
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000101
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000254
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000257
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_20161102D.html
https://curl.haxx.se/docs/adv_20161102E.html
https://curl.haxx.se/docs/adv_20161102F.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_20161221A.html
https://curl.haxx.se/docs/adv_20170403.html
https://curl.haxx.se/docs/adv_20170809A.html
https://curl.haxx.se/docs/adv_20170809B.html
https://curl.haxx.se/docs/adv_20171004.html
https://curl.haxx.se/docs/adv_20171023.html
https://curl.haxx.se/docs/adv_2017-12e7.html
https://curl.haxx.se/docs/adv_2017-ae72.html
========================

Updated packages in core/updates_testing:
========================
curl-7.40.0-3.14.mga5
libcurl4-7.40.0-3.14.mga5
libcurl-devel-7.40.0-3.14.mga5
curl-examples-7.40.0-3.14.mga5

from curl-7.40.0-3.14.mga5.src.rpm

Keywords: feedback => (none)
Assignee: shlomif => qa-bugs

Comment 26 Lewis Smith 2017-12-30 11:46:14 CET
Warrants proper testing.
Dave Hodgins 2017-12-31 07:10:41 CET

Keywords: (none) => advisory

Comment 27 Dave Hodgins 2018-01-01 09:58:11 CET
Tested using drakrpm set to use curl, and then using it to install other updates.

Validating the update.

Keywords: (none) => validated_update
Whiteboard: (none) => MGA5-32-OK MGA6-64-OK
CC: (none) => sysadmin-bugs

Comment 28 Mageia Robot 2018-01-03 17:41:07 CET
An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2018-0053.html

Resolution: (none) => FIXED
Status: NEW => RESOLVED


Note You need to log in before you can comment on or make changes to this bug.