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.
This is still a problem on F18, but I've reproduced it with dnsmasq alone, so I'm retitling and reassigning this bug. Using dnsmasq-2.65-1.fc18.x86_64, the difference is demonstrated between --bind-dynamic and the old --bind-interfaces. A local query to dnsmasq --bind-dynamic works in TCP, but times out in UDP: # dnsmasq --no-daemon --conf-file= --bind-dynamic --interface em1 --except-interface lo $ dig +tcp +short @192.168.1.203 localhost 127.0.0.1 $ dig +notcp +short @192.168.1.203 localhost ;; connection timed out; no servers could be reached The same query with --bind-interfaces works fine either way: # dnsmasq --no-daemon --conf-file= --bind-interfaces --interface em1 --except-interface lo $ dig +tcp +short @192.168.1.203 localhost 127.0.0.1 $ dig +notcp +short @192.168.1.203 localhost 127.0.0.1
Thank you for your report, Josh. I am going to steal this bug to be a security response product one (the issue is a security flaw). More details to come.
Old issue #1 - Originally, Common Vulnerabilities and Exposures assigned an identifier CVE-2012-3411 to the following vulnerability: 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. http://www.openwall.com/lists/oss-security/2012/07/12/5 -- New issue #2 - Later 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.
CVE request: http://www.openwall.com/lists/oss-security/2013/01/18/2
I contacted upstream to discuss possible fix.
This issue did NOT affect the version of the dnsmasq package, as shipped with Red Hat Enterprise Linux 5 as the fix for the original CVE-2012-3411 issue has not been applied yet to version of dnsmasq as shipped with Red Hat Enterprise Linux 5. -- This issue did NOT affect the version of the dnsmasq package, as shipped with Red Hat Enterprise Linux 6. The fix in Red Hat Enterprise Linux 6 is based on different logic and as such is immune to the incomplete fix behaviour. -- This issue affects the versions of the dnsmasq package, as shipped with Fedora release of 17 and 18. Please schedule an update (once there is final upstream patch available).
Created dnsmasq tracking bugs for this issue Affects: fedora-all [bug 901555]
Statement: Not vulnerable. This issue did not affect the versions of dnsmasq as shipped with Red Hat Enterprise Linux 5 and 6.
Created attachment 682464 [details] Proposed patch from upstream Proposed patch. I'll do some testing.
CVE-2013-0198 assigned: http://www.openwall.com/lists/oss-security/2013/01/18/7
There is one more thing for you Josh. Once we will fix this CVE it will not fix the issue you have described in the original Bug description. After the fix dnsmasq will not answer UDP nor TCP local DNS queries. The only solution how to get things working as before, libvirt would have to run dnsmasq instances WITHOUT "--except-interface lo" option. I'm not sure what is the reason for using this option in libvirt's case. So you will have to file a new Bug on libvirt once this issue is fixed if you want dnsmasq behave the same way as you were used to. Maybe they can add some way how to configure if the --except-interface option is used. Sorry for this.
(In reply to comment #15) > There is one more thing for you Josh. Once we will fix this CVE it will not > fix the issue you have described in the original Bug description. After the > fix dnsmasq will not answer UDP nor TCP local DNS queries. > > The only solution how to get things working as before, libvirt would have to > run dnsmasq instances WITHOUT "--except-interface lo" option. I'm not sure > what is the reason for using this option in libvirt's case. > > So you will have to file a new Bug on libvirt once this issue is fixed if > you want dnsmasq behave the same way as you were used to. Maybe they can add > some way how to configure if the --except-interface option is used. > > Sorry for this. Libvirt is set up to parse dnsmasq capabilities from --help and --version output. But we'd need a distinct string that we can find from newer dnsmasq (where --except-interface lo must NOT be used) in contrast to earlier dnsmasq (where it should probably still be used, to avoid a repeat of bug 886663).
(In reply to comment #16) > Libvirt is set up to parse dnsmasq capabilities from --help and --version > output. But we'd need a distinct string that we can find from newer dnsmasq > (where --except-interface lo must NOT be used) in contrast to earlier > dnsmasq (where it should probably still be used, to avoid a repeat of bug > 886663). I see it won't be that easy. Bug #886663 would happen also after fixing this CVE. I will investigate if and how it could be fixed. Thank you for pointing this out.
(In reply to comment #15) > There is one more thing for you Josh. Once we will fix this CVE it will not > fix the issue you have described in the original Bug description. After the > fix dnsmasq will not answer UDP nor TCP local DNS queries. Indeed, I reported that the glass was half full, and you decided it should be empty... :P > The only solution how to get things working as before, libvirt would have to > run dnsmasq instances WITHOUT "--except-interface lo" option. I'm not sure > what is the reason for using this option in libvirt's case. At least with dnsmasq-2.65-1.fc18, if you don't specify the exception, it will still bind to 127.0.0.1 and [::1], which it shouldn't per bug #886663. (In reply to comment #16) > Libvirt is set up to parse dnsmasq capabilities from --help and --version > output. But we'd need a distinct string that we can find from newer dnsmasq > (where --except-interface lo must NOT be used) in contrast to earlier > dnsmasq (where it should probably still be used, to avoid a repeat of bug > 886663). Is there yet any version which can do what I'm hoping for? I couldn't find any combination of options to make it work. In short, I'd like DNS to answer on 192.168.122.1 either through virbr0 or locally. It should not listen to localhost addresses (per 886663) nor any other interfaces (per these CVEs). Perhaps this should be duped into a separate bug as a feature request?
(In reply to comment #18) > Indeed, I reported that the glass was half full, and you decided it should > be empty... :P True :) The current behaviour is not very secure. > At least with dnsmasq-2.65-1.fc18, if you don't specify the exception, it > will still bind to 127.0.0.1 and [::1], which it shouldn't per bug #886663. The combination of options used when running dnsmasq is controlled by libvirt. > Is there yet any version which can do what I'm hoping for? I couldn't find > any combination of options to make it work. You have to look for changes in libvirt. Regarding to libvirt's changelog you would want to use version 0.9.11.8-1, but unfortunately it was deleted. > In short, I'd like DNS to answer on 192.168.122.1 either through virbr0 or > locally. It should not listen to localhost addresses (per 886663) nor any > other interfaces (per these CVEs). Perhaps this should be duped into a > separate bug as a feature request? New bug would be better to track your issue.
Upstream commit fixing this CVE: http://www.thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=22ce550e5346947a12a781ed0959a7b1165d0dc6
(In reply to comment #19) > (In reply to comment #18) > > At least with dnsmasq-2.65-1.fc18, if you don't specify the exception, it > > will still bind to 127.0.0.1 and [::1], which it shouldn't per bug #886663. > > The combination of options used when running dnsmasq is controlled by > libvirt. Right, but I was trying to find what manual dnsmasq options would fully do the right thing, as a prerequisite before I can ask libvirt to make changes.
(In reply to comment #21) > Right, but I was trying to find what manual dnsmasq options would fully do > the right thing, as a prerequisite before I can ask libvirt to make changes. All libvirt dnsmasq instances would need to remove "--except-interface lo" from their options. However, once this is done, it is no longer to start up any dnsmasq instance that has "--bind-interfaces" without *that* dnsmasq also having --except-interface lo; in particular, you won't be able to start a dnsmasq that is listening for queries on 127.0.0.1/lo. Note that it *is* possible for another dnsmasq with "--bind-dynamic --listen-address 127.0.0.1" to be started, but that's not what's being done. Again, you can get details on that from Bug 886663.
(In reply to comment #22) > (In reply to comment #21) > > > Right, but I was trying to find what manual dnsmasq options would fully do > > the right thing, as a prerequisite before I can ask libvirt to make changes. > > All libvirt dnsmasq instances would need to remove "--except-interface lo" > from their options. However, once this is done, it is no longer to start up > any dnsmasq instance that has "--bind-interfaces" without *that* dnsmasq > also having --except-interface lo; in particular, you won't be able to start > a dnsmasq that is listening for queries on 127.0.0.1/lo. > > Note that it *is* possible for another dnsmasq with "--bind-dynamic > --listen-address 127.0.0.1" to be started, but that's not what's being done. > Again, you can get details on that from Bug 886663. I would like NM's dnsmasq to answer 127.0.0.1 (by nature lo), and libvirt's to answer 192.168.122.1 on virbr0 or lo. The fact that NM's can still start by using --bind-dynamic doesn't mean it will be the one responding, as your bug 886663 comment 6 indicates. It seems you'd have a startup race for whoever really grabbed 127.0.0.1 first, and that's not ok. I'll file a separate bug later today to stop polluting this CVE, and from there hopefully it can be hashed out who among dnsmasq, libvirt, and/or NetworkManager can change their options to make this work, if it is possible at all.
(In reply to comment #23) > I would like NM's dnsmasq to answer 127.0.0.1 (by nature lo), and libvirt's > to answer 192.168.122.1 on virbr0 or lo. The fact that NM's can still start > by using --bind-dynamic doesn't mean it will be the one responding, as your > bug 886663 comment 6 indicates. It seems you'd have a startup race for > whoever really grabbed 127.0.0.1 first, and that's not ok. dnsmasq with --except-interface lo will *NOT* bind to the loopback interface this means the 127.0.0.1 will be available. Since CVE-2012-3411 and CVE-2013-0198 were fixed, libvirt's dnsmasq will *NOT* answer any DNS Queries coming on another interface that virbrX. Answering DNS Queries coming through lo with --except-interface lo used was an error. > I'll file a separate bug later today to stop polluting this CVE, and from > there hopefully it can be hashed out who among dnsmasq, libvirt, and/or > NetworkManager can change their options to make this work, if it is possible > at all. This could be resolved by implementing new option for dnsmasq, to enable local DNS Queries (without binding to lo). It would need to be used by libvirt. Please create the new Bug for dnsmasq. As a workaround you could use --bind-interfaces instead of --bind-dynamic for libvirt's dnsmasq instances, but *BE AWARE* that: 1. Using this you will be vulnerable to CVE-2012-3411 and CVE-2013-0198! 2. If libvrt's dnsmasq binds to a *PUBLIC IP* then *DON'T DO THIS*! 3. USE THIS WORKAROUND ON YOUR OWN RISK, YOU HAVE BEEN ADVISED!
Josh, I created Bug #904940 to track the original issue.
dnsmasq-2.65-4.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
dnsmasq-2.65-4.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.