Bug 894486 (CVE-2013-0198)

Summary: CVE-2013-0198 dnsmasq: Incomplete fix for the CVE-2012-3411 issue
Product: [Other] Security Response Reporter: Josh Stone <jistone>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: aquini, berrange, clalancette, eblake, itamar, jforbes, jlieskov, jrusnack, jyang, laine, libvirt-maint, simon, thozza, veillard, virt-maint
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: impact=low,public=20130111,reported=20130118,source=redhat,cvss2=2.6/AV:N/AC:H/Au:N/C:N/I:N/A:P,rhel-5/dnsmasq=notaffected,rhel-6/dnsmasq=notaffected,fedora-all/dnsmasq=affected
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-02-27 05:11:30 EST Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On: 886663, 901555    
Bug Blocks: 838539    
Attachments:
Description Flags
Proposed patch from upstream none

Description 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 1 Josh Stone 2013-01-17 14:30:07 EST
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
Comment 2 Jan Lieskovsky 2013-01-18 08:09:54 EST
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.
Comment 3 Jan Lieskovsky 2013-01-18 08:25:10 EST
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.
Comment 4 Jan Lieskovsky 2013-01-18 08:33:36 EST
CVE request:
  http://www.openwall.com/lists/oss-security/2013/01/18/2
Comment 5 Tomáš Hozza 2013-01-18 08:46:44 EST
I contacted upstream to discuss possible fix.
Comment 6 Jan Lieskovsky 2013-01-18 08:51:07 EST
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).
Comment 7 Jan Lieskovsky 2013-01-18 08:51:52 EST
Created dnsmasq tracking bugs for this issue

Affects: fedora-all [bug 901555]
Comment 9 Jan Lieskovsky 2013-01-18 09:09:21 EST
Statement:

Not vulnerable. This issue did not affect the versions of dnsmasq as shipped with Red Hat Enterprise Linux 5 and 6.
Comment 11 Tomáš Hozza 2013-01-18 09:57:15 EST
Created attachment 682464 [details]
Proposed patch from upstream

Proposed patch. I'll do some testing.
Comment 13 Vincent Danen 2013-01-19 13:26:44 EST
CVE-2013-0198 assigned:

http://www.openwall.com/lists/oss-security/2013/01/18/7
Comment 15 Tomáš Hozza 2013-01-21 14:08:04 EST
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.
Comment 16 Eric Blake 2013-01-21 15:27:37 EST
(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).
Comment 17 Tomáš Hozza 2013-01-21 15:46:02 EST
(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.
Comment 18 Josh Stone 2013-01-21 16:05:37 EST
(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?
Comment 19 Tomáš Hozza 2013-01-22 06:51:31 EST
(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.
Comment 21 Josh Stone 2013-01-23 18:59:05 EST
(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.
Comment 22 Laine Stump 2013-01-24 13:09:10 EST
(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.
Comment 23 Josh Stone 2013-01-24 13:31:15 EST
(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.
Comment 24 Tomáš Hozza 2013-01-25 02:47:44 EST
(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!
Comment 25 Tomáš Hozza 2013-01-28 03:44:33 EST
Josh, I created Bug #904940 to track the original issue.
Comment 26 Fedora Update System 2013-02-11 23:58:28 EST
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.
Comment 27 Fedora Update System 2013-02-18 02:05:16 EST
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.