|
Message-ID: <b7fbe4e4-9dc5-3872-903c-a16b9ff43c58@brad-house.com> Date: Mon, 22 May 2023 08:26:29 -0400 From: Brad House <brad@...d-house.com> To: oss-security@...ts.openwall.com Cc: Daniel Stenberg <daniel@...x.se> Subject: c-ares multiple vulnerabilities: CVE-2023-32067, CVE-2023-31147, CVE-2023-31130, CVE-2023-31124 CVE-2023-32067 Impact Denial of Service. Attack Steps: 1. The target resolver sends a query 2. The attacker forges a malformed UDP packet with a length of 0 and returns them to the target resolver 3. The target resolver erroneously interprets the 0 length as a graceful shutdown of the connection. (this is only valid for TCP connections, UDP is connection-less) 4. Current resolution fails, DoS attack is achieved. Patches Patched in 1.19.1 Workarounds No workarounds are available. Credit Xiang Li Network and Information Security Laboratory, Tsinghua University ---------- CVE-2023-31124 Impact When cross-compiling c-ares and using the autotools build system, CARES_RANDOM_FILE 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. Patches Patched in 1.19.1 Workarounds Use CMake build system Credit David Gstir and Hannes Moesl X41 D-SEC GmbH Audit funded by Open Source Technology Improvement Fund (OSTIF) ---------- CVE-2023-31130 Impact ares_inet_net_pton() 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 ares_set_sortlist(). However, users may externally use ares_inet_net_pton() for other purposes and thus be vulnerable to more severe issues. Patches Fixed in 1.19.1 Workarounds No workarounds are available. Credit Hannes Moesl X41 D-SEC GmbH Audit funded by Open Source Technology Improvement Fund (OSTIF) ---------- CVE-2023-31147 Impact Description of issue(s): 1. 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. 2. 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. 3. No attempt is made to look for modern OS-provided CSPRNGs like arc4random() that is widely available. Correction(s) made: 1. Detect arc4random() and if available, use it directly to generate DNS query ids. 2. Use /dev/urandom or RtlGenRandom() directly to generate DNS query ids as a fallback 3. As a last resort, use the current rand() + RC4 logic (should only apply to esoteric systems), with these modifications: * replace RC4 implementation with official algorithm * seed rand() using srand() Patches Fixed in 1.19.1 Workarounds No workarounds are available. Credit David Gstir and Hannes Moesl X41 D-SEC GmbH Audit funded by Open Source Technology Improvement Fund (OSTIF)
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.