CVE-2008-4392 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-4392): dnscache in Daniel J. Bernstein djbdns 1.05 does not prevent simultaneous identical outbound DNS queries, which makes it easier for remote attackers to spoof DNS responses, as demonstrated by a spoofed A record in the Additional section of a response to a Start of Authority (SOA) query.
This bug has been fixed with -r22.
(In reply to comment #1) > This bug has been fixed with -r22. > uhrm, please don't close security bugs.
Arches, please test and mark stable: =net-dns/djbdns-1.05-r22 Target keywords : "alpha amd64 hppa ppc ppc64 sparc x86"
anyone hit this patch problem not applying... djbdns-1.05-test23.diff.bz2
Created attachment 183744 [details] djbdns-1.05-test23.diff.bz2-11758.out (In reply to comment #4) > anyone hit this patch problem not applying... > > djbdns-1.05-test23.diff.bz2 Yes.
@killerfox: Could you drop that patch or get it fixed, please?
Fixed. Wrong patch order.
!!! newbin: /keeps/gentoo/portage/net-dns/djbdns/files/djbdns-setup-r22 does not exist
ppc64 done
Stable on alpha.
Since this package has many flags that are not turned on by default, could you guys provide any feedback on how to test it? Or is it ok to you if i only perform compile test only?
Stable for HPPA (also fixed the issue of comment #8 in that commit).
amd64/x86 stable
ppc done
What about bug #260975?
(In reply to comment #15) > What about bug #260975? It has been reported after this bug went into [stable], so we felt like keeping this running and attach arches to the other bug when it's been committed.
It appears there are some issues with this qmerge patch. http://marc.info/?t=123608914400003&r=1&w=2
sparc already has =net-dns/djbdns-1.05-r23 stable, bug #260975 I assume we don't need -r22 then, if we do please re-cc us.
has there been upstream reaction concerning the regression? I only see it being discussed for the zinq fork.
(In reply to comment #19) > has there been upstream reaction concerning the regression? I only see it being > discussed for the zinq fork. There has been no word on this particular problem from DJB. Jeff King has been working on a patch to stock djbdns that Mark Johnson, the zinq maintainer, hopes to include in zinq. Jeff's first patch (the one included in the current ebuild) was flawed even by Jeff's admission. There's a new version here: http://marc.info/?l=djbdns&m=123859517723684&w=2 But it seems it hasn't received much testing/feedback yet. I would highly recommend not including any version of the patch until the djbdns list has sorted it out; otherwise things may break as they do with the first patch.
with the known regression and a new patch evolving slowly, we should probably remove the patch (downgrade won't work due to the other patch in -r23).
With the regressions in our current stable, it seems more sensible to merge the new version of the patch. Feedback on it has been positive except for higher CPU usage: http://thread.gmane.org/gmane.network.djbdns/13965
There is no <net-dns/djbdns-1.05-r23 in portage any more.
I think this can be closed; all affected versions are gone from the tree.
@security, is there a reason this is still open? If no, can we get it closed please?
(In reply to comment #25) > @security, is there a reason this is still open? If no, can we get it closed > please? Thanks for the poke. We need to vote on whether or not this requires a GLSA, and if it does, we'll need to publish one before we can close this bug. GLSA Vote: no.
voting no too, and closing.
