Bug 8795 - dnsmasq - Incomplete fix for the CVE-2012-3411 issue (CVE-2013-0198)
: dnsmasq - Incomplete fix for the CVE-2012-3411 issue (CVE-2013-0198)
Status: RESOLVED FIXED
Product: Mageia
Classification: Unclassified
Component: Security
: 2
: i586 Linux
: Normal Severity: normal
: ---
Assigned To: QA Team
:
: http://cve.mitre.org/cgi-bin/cvename....
: has_procedure MGA2-64-OK MGA2-32-OK
: validated_update
:
:
  Show dependency treegraph
 
Reported: 2013-01-23 19:13 CET by Oden Eriksson
Modified: 2013-02-06 23:07 CET (History)
5 users (show)

See Also:
Source RPM: dnsmasq
CVE:


Attachments

Description Oden Eriksson 2013-01-23 19:13:08 CET
https://bugzilla.redhat.com/show_bug.cgi?id=894486

"Josh Stone 2013-01-11 16:03:31 EST

Description of problem:
On my workstation, as a virtual machine host, I have NetworkManager's dnsmasq configured to forward DNS queries for a local domain to 192.168.122.1, so I can resolve those to virtual machine DHCP hostnames.  Recently this stopped working.

With manual dig commands, I found that TCP queries still work, but UDP doesn't.  For example, in libvirt I have a statically defined name "vhost" to 192.168.122.1 itself.  From the host, the command "dig +short +tcp @192.168.122.1 vhost" resolves that just fine.  But "dig +short +notcp @192.168.122.1 vhost" says "connection timed out; no servers could be reached".  From a guest, +tcp and +notcp both work fine.

Version-Release number of selected component (if applicable):
libvirt-0.9.11.8-2.fc17.x86_64, dnsmasq-2.63-1.fc17.x86_64
I also tried dnsmasq-2.65-1.fc17.x86_64 from updates-testing

How reproducible:
100%

Steps to Reproduce:
1. From the virtual machine host, try to query the libvirt dnsmasq.
  
Actual results:
$ dig +short +tcp @192.168.122.1 vhost
192.168.122.1
$ dig +short +notcp @192.168.122.1 vhost
;; connection timed out; no servers could be reached

Expected results:
A positive answer from both TCP and UDP queries.

Additional info:
I suspect this is related to the fixes for CVE-2012-3411, but it seems weird that UDP and TCP would be treated differently."
Comment 2 Julien Moragny 2013-01-31 23:27:18 CET
Hi,

thanks for the report.
I've just pushed dnsmasq-2.65-3.mga3 to cauldron with the patch from redhat to fix this CVE (here is the patch: https://bugzilla.redhat.com/show_bug.cgi?id=901555).

I will prepare an update for mga2 ASAP.

regards
Julien
Comment 3 Julien Moragny 2013-02-01 21:10:53 CET
Here is the update for mga2, procedure for testing documented by Claire Robinson in bug #7466 :
https://bugs.mageia.org/show_bug.cgi?id=7466#c9


Proposal of advisory:
========================

Updated dnsmasq packages fix security vulnerabilities (CVE-2013-0198):

This update complete the fix for CVE-2012-3411 provided with dnsmasq-2.63.
It was found that after the upstream patch for CVE-2012-3411 issue was applied, dnsmasq still:
 - replied 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.

This update fix these three cases.

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-0198
https://bugzilla.redhat.com/show_bug.cgi?id=901555
https://bugzilla.redhat.com/show_bug.cgi?id=894486
========================

Updated packages in core/updates_testing:
========================
dnsmasq-2.63-1.1.mga2
dnsmasq-base-2.63-1.1.mga2

Source RPM: 
dnsmasq-2.63-1.1.mga2.src.rpm
Comment 4 Julien Moragny 2013-02-01 21:13:21 CET
Hi QA,

I just pushed an update of dnsmasq for mga2.
You can find the advisory and a procedure to test in previous comments.

Thank you
regards
Julien
Comment 5 claire robinson 2013-02-03 17:01:18 CET
Testing procedure: https://bugs.mageia.org/show_bug.cgi?id=7466#c9
Comment 6 David Walser 2013-02-05 20:44:51 CET
Patch checked into Mageia 1 SVN.
Comment 7 Dave Hodgins 2013-02-05 22:25:45 CET
With dnsmasq-2.63-1.mga2 from Core Updates, I cannot reproduce the problem.
Both of my virtualbox installs (one i586, and one x86_64) are responding
to dig +notcp commands run from the host.

Oden, how are you running the virtual systems?
Comment 8 Oden Eriksson 2013-02-05 22:40:04 CET
I did only the reporting here.
Comment 9 Dave Hodgins 2013-02-05 22:44:19 CET
Ok.  I'll go ahead and install the updates testing version, and just
test that they are working properly.
Comment 10 Dave Hodgins 2013-02-05 23:01:05 CET
I noticed that when I installed the updates testing version, the dnsmasq
service did not get restarted.  Perhaps in future, automatic restarting
could be added as an enhancement.

Testing complete on Mageia 2 i586 and x86_64.

Could someone from the sysadmin team push the srpm
dnsmasq-2.63-1.1.mga2.src.rpm
from Mageia 2 Core Updates Testing to Core Updates.

Advisory: Updated dnsmasq packages fix security vulnerabilities (CVE-2013-0198):

This update complete the fix for CVE-2012-3411 provided with dnsmasq-2.63.
It was found that after the upstream patch for CVE-2012-3411 issue was applied,
dnsmasq still:
 - replied 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.

This update fix these three cases.

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-0198
https://bugzilla.redhat.com/show_bug.cgi?id=901555
https://bugzilla.redhat.com/show_bug.cgi?id=894486

https://bugs.mageia.org/show_bug.cgi?id=8795
Comment 11 Thomas Backlund 2013-02-06 23:07:56 CET
Update pushed:
https://wiki.mageia.org/en/Support/Advisories/MGASA-2013-0030

Note You need to log in before you can comment on or make changes to this bug.