Just noticed that <net-dns/c-ares-1.5.3 is affected by vulnerability CVE-2008-1447. There is thread in upstream mailing list: http://www.mail-archive.com/c-ares@cool.haxx.se/msg00059.html This item in the CHANGES: * Aug 4 2008 (Daniel Stenberg) - Fix by Tofu Linden: The symptom: * Users (usually, but not always) on 2-Wire routers and the Comcast service and a wired connection to their router would find that the second and subsequent DNS lookups from fresh processes using c-ares to resolve the same address would cause the process to never see a reply (it keeps polling for around 1m15s before giving up). The repro: * On such a machine (and yeah, it took us a lot of QA to find the systems that reproduce such a specific problem!), do 'ahost www.secondlife.com', then do it again. The first process's lookup will work, subsequent lookups will time-out and fail. The cause: * init_id_key() was calling randomize_key() *before* it initialized key->state, meaning that the randomness generated by randomize_key() is immediately overwritten with deterministic values. (/dev/urandom was also being read incorrectly in the c-ares version we were using, but this was fixed in a later version.) * This makes the stream of generated query-IDs from any new c-ares process be an identical and predictable sequence of IDs. * This makes the 2-Wire's default built-in DNS server detect these queries as probable-duplicates and (erroneously) not respond at all. And this is fixed in c-ares-1.5.3. I think it's time to stabilize c-ares-1.5.3.
Well, not sure CVE-2008-1447 should be used here. CVE-2008-1447 is about a new way to make cache poisoning of caching resolvers easier (once success in a race hijacks whole domain), proving that fixed / predictable source ports are not secure enough. Comment #0 points out 2 issue: - Mailing list thread is about recv -> recvfrom change. This change does not see to have a big security impact, as 1) DNS is UDP, and 2) when someone is trying to poison, crafted packets with spoofed source address are used anyway. - Changelog entry is about incorrect PRNG seeding, resulting in fixed / predictable transaction ID stream. So not too close to -1447 as well, probably closer to Amit Klein's work from 2007 (iirc). Quick testing with ahost, this seems to be fixed in 1.5.3. Also testing with ahost (as ahost host1 host2 host3 ...), all requests seem to use the same source port even in 1.5.3 (i.e. similarity to fixes/mitigations for -1447), but as c-ares is stub resolver (similar to glibc) and does not seem to do any caching, the impact much lower (one race win -> single resolution poisoned).
wow - thanks Tomas for the analysis. stable request for 1.5.3 (1.6.0 is a ABI bump)
ppc64 done
amd64/x86 stable
ppc stable
Stable on alpha.
mips is ~arch only.
Stable for HPPA.
arm/ia64/s390/sh/sparc stable
Rating as B3 as discussed on IRC.
I vote YES, easy attack vector and this should be documented in a GLSA.
Yes, too. Request filed.
This issue has been fixed since Feb 04, 2009. No GLSA will be issued.
