From $URL : the CVE-2012-3411 identifier has been originally assigned to the following issue: When dnsmasq is used in conjunctions with certain configurations of libvirtd, network packets from prohibited networks (e.g. packets that should not be passed in) may be sent to the dnsmasq application and processed. This can result in DNS amplification attacks for example. [1] http://www.openwall.com/lists/oss-security/2012/07/12/5 Later it was found: [2] https://bugzilla.redhat.com/show_bug.cgi?id=894486 [3] https://bugzilla.redhat.com/show_bug.cgi?id=894486#c3 the upstream patch for CVE-2012-3411 it not to be working properly, as it still allowed (from [3]): * replies to remote TCP-protocol based DNS queries (UDP protocol ones were corrected, but TCP ones not) from prohibited networks, when the --bind-dynamic option was used, * when --except-interface lo option was used dnsmasq didn't answer local or remote UDP DNS queries, but still allowed TCP protocol based DNS queries, * when --except-interface lo option was not used local / remote TCP DNS queries were also still answered by dnsmasq.
CVE-2013-0198 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-0198): Dnsmasq before 2.66test2, when used with certain libvirt configurations, replies to queries from prohibited interfaces, which allows remote attackers to cause a denial of service (traffic amplification) via spoofed TCP based DNS queries. NOTE: this vulnerability exists because of an incomplete fix for CVE-2012-3411.
I will pull in 2.66 final when it comes out with the fix, unless someone submits a separated patch that applies against 2.65.
net-dns/dnsmasq-2.66 is now in the tree containing the fix for this
(In reply to comment #3) > net-dns/dnsmasq-2.66 is now in the tree containing the fix for this And ready to go stable?
Yeah it's ready to go stable. Sorry about the delay in responding here.
Arches, please test and mark stable: =net-dns/dnsmasq-2.66 Target KEYWORDS: "alpha amd64 arm hppa ia64 ~mips ppc ppc64 s390 sh sparc x86 ~sparc-fbsd ~x86-fbsd"
Stable for HPPA.
amd64 stable
x86 stable
alpha stable
arm stable
ia64 stable
ppc64 stable
ppc stable
sparc stable
s390 stable
sh stable
GLSA vote: yes
Poke, 8 months passed.
GLSA Vote: Yes Created a New GLSA request.
This issue was resolved and addressed in GLSA 201406-24 at http://security.gentoo.org/glsa/glsa-201406-24.xml by GLSA coordinator Mikle Kolyada (Zlogene).
