CVE-2012-1191 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2012-1191): The resolver in dnscache in Daniel J. Bernstein djbdns 1.05 overwrites cached server names and TTL values in NS records during the processing of a response to an A record query, which allows remote attackers to trigger continued resolvability of revoked domain names via a "ghost domain names" attack.
Does anyone have an opinion about whether or not we should patch this? The fix recommended in the paper is easy to implement: we just ignore NS updates unless they come from the delegating parent. As mentioned in the paper, this has two negative side effects: 1. Performance. You have to go one level up the hierarchy to get NS updates. In my opinion not a big deal. 2. Some misconfigurations may stop working. If example.com's parent has different NS records for example.com than the nameservers for example.com do, the fix could expose that fact. The DNS spec forbids this, but I have no idea how prevalent it is in practice.
Maybe this should go upstream first? Let them decide what to do
(In reply to comment #2) > Maybe this should go upstream first? Let them decide what to do Upstream is essentially dead. DJB released the code into the public domain and no patches have been merged with the official source ever since. There are a few people maintaining forks. Some just apply patches, others attempt to do away with the build system and daemontools. None of them really have critical mass yet though so I'm wary of switching. None of the forks have patched this issue, but there was some discussion and a patch on the mailing list.
(In reply to Michael Orlitzky from comment #3) > None of the forks have patched this issue, but there was some discussion and > a patch on the mailing list. Do you have a link to that mail/discussion?
(In reply to Michael Weber from comment #4) > (In reply to Michael Orlitzky from comment #3) > > None of the forks have patched this issue, but there was some discussion and > > a patch on the mailing list. > Do you have a link to that mail/discussion? http://marc.info/?t=134184388900003&r=1&w=2
@maintainer, what can be done here? Please let us know... thanks!
@ Maintainer: Please consider https://github.com/pjps/ndjbdns/commit/c90dbbbac5622e2744733f39e037263e63b51266 (that's the patch RH is using; Do to different code style you will have to adjust the patch but it does apply between line 794 and 795). And maybe consider moving to ndjbdns src in general, see http://pjp.dgplug.org/ndjbdns/ for additional missing fixes.
This isn't a serious vulnerability, it's an obscure flaw in the way the DNS protocol was designed. The proof-of-concept is cool, but not practical, and there are no real-world situations where 1. An attacker can influence my DNS cache, 2. That attacker is trying to send me to an expired domain, 3. It's problematic if I can still resolve the expired name. More practically: no one should be using dnscache any more. I recommend net-dns/unbound instead, but unfortunately, dnscache comes with net-dns/djbdns, and the latter still provides some other useful daemons like tinydns. I can set up dnscache locally, but the proof-of-concept is complex. So, there's a trade-off to consider: 1. We can do nothing. This leaves users of dnscache "vulnerable," but to what, I have no idea. If someone can think of a practical attack, I'll change my position on the matter. 2. I can use the patch. It doesn't apply cleanly, I don't understand the code, I don't use dnscache in production, and the proof-of-concept is too complex so we won't even know if the issue is fixed or not. The question is, which option above is more dangerous? I'm guessing option #2 is more likely to cause some kind of problem.
(In reply to Michael Orlitzky from comment #8) > [...] > 2. I can use the patch. It doesn't apply cleanly, I don't understand the > code, I don't use dnscache in production, and the proof-of-concept is > too complex so we won't even know if the issue is fixed or not. > > The question is, which option above is more dangerous? I'm guessing option > #2 is more likely to cause some kind of problem. I can provide a backport if needed. It is only a code formation issue. But before we do that, some additional questions: 1) Switching to ndjbdns is not an option? Their patch set is more complete and actively maintained than the cherry-picked patch set we have. 2) We could also get rid of dnscache, i.e. remove it from $D in src_install.
(In reply to Thomas Deutschmann from comment #9) > > But before we do that, some additional questions: > > 1) Switching to ndjbdns is not an option? Their patch set is more complete > and actively maintained than the cherry-picked patch set we have. ndjbdns would need to be a new, separate, package (see bug #420013). In particular, ndjbdns uses a different build and init system, so it's not a drop-in replacement, and the ebuild would be completely different. It's also missing ipv6 support which we patch in. I do actively maintain our patch set; the latest addition was on 2016-08-05. But I'm not very familiar with the code, so I try to be judicious about what I blindly apply, especially when I can't test the result and the benefit is dubious. > 2) We could also get rid of dnscache, i.e. remove it from $D in src_install. I'm not strongly against this. DNS cache configuration is simple, so while net-dns/unbound isn't a drop-in replacement, you can do it in about 15 minutes. But, I'm sure we do have active dnscache users. Do we really want to annoy them over this CVE? Anyone can get a CVE for something silly, and I'm not impressed by this one.
PR created, see https://github.com/gentoo/gentoo/pull/2988
PR was merged, https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f19fd949c1e9d06252fdb59c0f1fb0142cb7d9c8 @ Arches, please test and mark stable: =net-dns/djbdns-1.05-r32
Stable on alpha.
amd64 stable
x86 stable
Stable for HPPA.
sparc stable
ppc stable
ppc64 stable. Maintainer(s), please cleanup. Security, please vote.
All vulnerable versions have been removed, thanks.
GLSA Vote: No
