Hannes Moesl

The issue arises when /dev/urandom or RtlGenRandom() are unavailable, and c-ares uses `rand()` to generate random numbers for DNS query ids. This approach is not a Cryptographically Secure PseudoRandom Number Generator (CSPRNG) and lacks seeding by `srand()`, resulting in predictable output. The input from the random number generator is then used in a non-compliant RC4 implementation, potentially weakening its strength. Modern OS-provided CSPRNGs, such as `arc4random()`, are not utilized.

The issue is related to a buffer underflow in the `ares inet net pton()` function for certain IPv6 addresses, such as "0::00:00:00/2". This function is used internally by c-ares 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, making them vulnerable to more severe issues.

The issue is related to the use of `rand()` as a fallback when `CARES RANDOM FILE` is not set, which can allow an attacker to exploit the lack of entropy by not using a Cryptographically Secure Pseudorandom Number Generator (CSPRNG). This can potentially impact the integrity of protected information. The issue is specifically observed when cross-compiling c-ares for aarch64 android using the autotools build system.