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