c-ares : Use-after-free / double-free in c-ares query-completion handling, remotely triggerable via aresgetaddrinfo() over TCP

c-ares has a Use After Free vulnerability when connection is cleaned up after error

c-ares is an asynchronous resolver library. From 1.32.3 through 1.34.4, there is a use-after-free in readanswers() when processanswer() may re-enqueue a query either due to a DNS Cookie Failure or when the upstream server does not properly support EDNS, or possibly on TCP queries if the remote closed the connection immediately after a response. If there was an issue trying to put that new transaction on the wire, it would close the connection handle, but readanswers() was still expecting the connection handle to be available to possibly dequeue other responses. In theory a remote attacker might be able to trigger this by flooding the target with ICMP UNREACHABLE packets if they also control the upstream nameserver and can return a result with one of those conditions, this has been untested. Otherwise only a local attacker might be able to change system behavior to make send()/write() return a failure condition. This vulnerability is fixed in 1.34.5.

c-ares is a C library for asynchronous DNS requests. aresreadline() is used to parse local configuration files such as /etc/resolv.conf, /etc/nsswitch.conf, the HOSTALIASES file, and if using a c-ares version prior to 1.27.0, the /etc/hosts file. If any of these configuration files has an embedded NULL character as the first character in a new line, it can lead to attempting to read memory prior to the start of the given buffer which may result in a crash. This issue is fixed in c-ares 1.27.0. No known workarounds exist.

Buffer overflow vulnerability in c-ares before 1161 thru 1170 via function aresparsesoareply in aresparsesoareply.c.

CVE-2023-32067. 0-byte UDP payload causes Denial of Service (https://github.com/c-ares/c-ares/security/advisories/GHSA-9g78-jv2r-p7vc)

Description of issue(s): When /dev/urandom or RtlGenRandom() are unavailable, c-ares uses rand() to generate random numbers used for DNS query ids. This is not a CSPRNG, and it is also not seeded by srand() so will generate predictable output. Input from the random number generator is fed into a non-compilant RC4 implementation and may not be as strong as the original RC4 implementation. No attempt is made to look for modern OS-provided CSPRNGs like arc4random() that is widely available.

CVE-2023-31147 Insufficient randomness in generation of DNS query IDs (https://github.com/c-ares/c-ares/security/advisories/GHSA-8r8p-23f3-64c2)

aresinetnetpton() is vulnerable to a buffer underflow for certain ipv6 addresses, in particular "0::00:00:00/2" was found to cause an issue. C-ares only uses this function internally for configuration purposes which would require an administrator to configure such an address via aressetsortlist().

CVE-2023-31130. Moderate. Buffer Underwrite in aresinetnetpton() (https://github.com/c-ares/c-ares/security/advisories/GHSA-x6mf-cxr9-8q6v)

When cross-compiling c-ares and using the autotools build system, CARESRANDOMFILE will not be set, as seen when cross compiling aarch64 android. This will downgrade to using rand() as a fallback which could allow an attacker to take advantage of the lack of entropy by not using a CSPRNG.

CVE-2023-31124. Low. AutoTools does not set CARESRANDOMFILE during cross compilation (https://github.com/c-ares/c-ares/security/advisories/GHSA-54xr-f67r-4pc4)