Bug 886663 - libvirt-launched dnsmasq listens on localhost when it shouldn't
libvirt-launched dnsmasq listens on localhost when it shouldn't
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
18
Unspecified Unspecified
medium Severity medium
: ---
: ---
Assigned To: Laine Stump
Fedora Extras Quality Assurance
:
Depends On:
Blocks: CVE-2013-0198
  Show dependency treegraph
 
Reported: 2012-12-12 15:16 EST by Jeff Layton
Modified: 2014-06-18 03:42 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 886821 (view as bug list)
Environment:
Last Closed: 2013-01-06 15:13:05 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jeff Layton 2012-12-12 15:16:20 EST
I'm running libvirt-0.10.2.2-1.fc18.x86_64. I have my VPN config into work set up to run a dnsmasq on the loopback for split DNS. After the latest libvirt update however, I found that it failed to start because something was listening on the port. That something is the dnsmasq that libvirt fires up to handle virbr0:

[root@tlielax ~]# ps -ef | grep dnsmasq
nobody   12148     1  0 15:08 ?        00:00:00 /sbin/dnsmasq --strict-order --local=// --domain-needed --pid-file=/var/run/libvirt/network/default.pid --conf-file= --bind-dynamic --interface virbr0 --dhcp-range 192.168.122.2,192.168.122.254 --dhcp-leasefile=/var/lib/libvirt/dnsmasq/default.leases --dhcp-lease-max=253 --dhcp-no-override --dhcp-hostsfile=/var/lib/libvirt/dnsmasq/default.hostsfile --addn-hosts=/var/lib/libvirt/dnsmasq/default.addnhosts
root     12243 10766  0 15:09 pts/0    00:00:00 grep --color=auto dnsmasq
[root@tlielax ~]# lsof -p 12148 -n -P
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/4447/gvfs
      Output information may be incomplete.
COMMAND   PID   USER   FD      TYPE             DEVICE SIZE/OFF      NODE NAME
dnsmasq 12148 nobody  cwd       DIR              253,2     4096       128 /
dnsmasq 12148 nobody  rtd       DIR              253,2     4096       128 /
dnsmasq 12148 nobody  txt       REG              253,2   257584 206781719 /usr/sbin/dnsmasq
dnsmasq 12148 nobody  mem       REG              253,2   294560 136557603 /usr/lib64/libdbus-1.so.3.7.2
dnsmasq 12148 nobody  mem       REG              253,2    62416 137139879 /usr/lib64/libnss_files-2.16.so
dnsmasq 12148 nobody  mem       REG              253,2    44272 137139891 /usr/lib64/librt-2.16.so
dnsmasq 12148 nobody  mem       REG              253,2   141296 137139887 /usr/lib64/libpthread-2.16.so
dnsmasq 12148 nobody  mem       REG              253,2  2067976 136017844 /usr/lib64/libc-2.16.so
dnsmasq 12148 nobody  mem       REG              253,2   160344 136421458 /usr/lib64/ld-2.16.so
dnsmasq 12148 nobody    0u      CHR                1,3      0t0      1028 /dev/null
dnsmasq 12148 nobody    1u      CHR                1,3      0t0      1028 /dev/null
dnsmasq 12148 nobody    2u      CHR                1,3      0t0      1028 /dev/null
dnsmasq 12148 nobody    3u      REG              253,2        0  10904807 /var/lib/libvirt/dnsmasq/default.leases
dnsmasq 12148 nobody    4u     IPv4             272885      0t0       UDP *:67 
dnsmasq 12148 nobody    5u  netlink                         0t0    272886 ROUTE
dnsmasq 12148 nobody    6u     IPv4             272894      0t0       UDP 192.168.122.1:53 
dnsmasq 12148 nobody    7u     IPv4             272895      0t0       TCP 192.168.122.1:53 (LISTEN)
dnsmasq 12148 nobody    8u     IPv4             272896      0t0       UDP 127.0.0.1:53 
dnsmasq 12148 nobody    9u     IPv4             272897      0t0       TCP 127.0.0.1:53 (LISTEN)
dnsmasq 12148 nobody   10u     IPv6             272898      0t0       UDP [::1]:53 
dnsmasq 12148 nobody   11u     IPv6             272899      0t0       TCP [::1]:53 (LISTEN)
dnsmasq 12148 nobody   12r     FIFO                0,8      0t0    272904 pipe
dnsmasq 12148 nobody   13w     FIFO                0,8      0t0    272904 pipe
dnsmasq 12148 nobody   14u     unix 0xffff8803e74b2700      0t0    273464 socket

The dnsmasq launched by libvirt used to just listen on 192.168.122.1, but now it listens on the loopback too. That prevents my other dnsmasq server from starting and doesn't seem correct.

My suspicion would be this change in the changelog:

- CVE-2012-3411: avoid open DNS proxy with dnsmasq (bz #874702, bz #882309)

...but I'll leave the diagnosis to others to determine. Perhaps you still need the "--except-interface lo" in the command line as well?
Comment 1 Jeff Layton 2012-12-12 15:17:59 EST
Note too that if I start the libvirt virtual network after starting my other dnsmasq server that it doesn't end up listening on localhost.
Comment 2 Cole Robinson 2012-12-12 15:41:00 EST
Huh, I was hitting this too but didn't realize it was libvirt related.

I verified that adding '--except-interface lo' to the new 0.10.2.2 dnsmasq command line generates similar lsof output to 0.10.2.1 dnsmasq command line (basically what Jeff reported above, but without the 127.0.0.1 and [::1] bits)

The easiest way to have network manager run dnsmasq is adding 'dns=dnsmasq' to /etc/NetworkManager/NetworkManager.conf and logout/login

Laine, thoughts?
Comment 3 Jeff Layton 2012-12-12 16:00:29 EST
Yeah, in fact:

       -i, --interface=<interface name>
              Listen only on the specified interface(s). Dnsmasq automatically
              adds the loopback (local) interface to the list of interfaces to
              use  when  the --interface option  is used. If no --interface or
              --listen-address options are given dnsmasq listens on all avail‐
              able  interfaces except any given in --except-interface options.
              IP alias interfaces (eg "eth1:0") cannot be used  with  --inter‐
              face   or   --except-interface   options,  use  --listen-address
              instead.

...so if you don't include --except-interface=lo then it will the loopback automatically. Seems like a mis-feature to me, but whatever... ;)
Comment 4 Laine Stump 2012-12-12 21:35:23 EST
My recollection is that when I tried only switching --listen-address= to --interface=, the problem described in CVE 2012-3411 (Bug 833033) remained, but went away when I also removed --except-interface=lo. Something else could have been happening, so I'll double check tonight.
Comment 5 Laine Stump 2012-12-13 01:00:27 EST
Bah.

I apparently was lacking sleep when I tested, and gave too much credence to the suggestion in https://bugzilla.redhat.com/show_bug.cgi?id=833033#c36 . The bit that didn't get rid of the problem described in the CVE was adding --interface without removing --listen-address; leaving in --except-interface has no ill effects wrt. the CVE.

I'm creating patches now for all the affected branches.

Sorry for the inconvenience :-(
Comment 6 Laine Stump 2012-12-13 02:14:47 EST
BTW, I've just discovered that if the non-libvirt dnsmasq instance uses "bind-dynamic" instead of "bind-interfaces", it will be able to start; likewise if the non-libvirt dnsmasq is already running when libvirt starts its networks (even with "bind-interfaces" instead of "bind-dynamic" (I didn't check which dnsmasq actually receives the DNS requests sent to 127.0.0.1, since the answer will anyway be "the *wrong* one" in at least one of those cases)
Comment 7 Laine Stump 2012-12-13 04:10:41 EST
Fix posted upstream. Waiting for ACK:

https://www.redhat.com/archives/libvir-list/2012-December/msg00767.html

I did test that it both fixed this new problem, and didn't un-fix the CVE. I also posted a backport to the v0.10.2-maint branch, since the code being fixed is all changed since then, so a cherry-pick wouldn't suffice.

I don't know if it's any longer possible to get anything into F18, so this may have to be a 0-day update.
Comment 8 Fedora Update System 2012-12-16 15:05:21 EST
libvirt-0.10.2.2-2.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/libvirt-0.10.2.2-2.fc18
Comment 9 Fedora Update System 2012-12-18 10:17:47 EST
libvirt-0.10.2.2-3.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/libvirt-0.10.2.2-3.fc18
Comment 10 Adam Williamson 2012-12-18 17:41:33 EST
Stuff can still go into F18 but there needs to be a justification as to why it needs to go into the frozen package set and media rather than going out as a 0-day. If you want that, the mechanism is to mark the bug as blocking the bug 'F18-accepted' and add a comment to explain why we should break freeze for this bug. See https://fedoraproject.org/wiki/QA:SOP_nth_bug_process . thanks.
Comment 11 Adam Williamson 2012-12-18 17:42:29 EST
Note that https://bugzilla.redhat.com/show_bug.cgi?id=882309 is already acceptednth so we could fudge a bit and say we should take the newest libvirt to fix that, rather than just taking the build which fixed that but also introduced this regression.
Comment 12 Adam Williamson 2012-12-18 17:44:01 EST
sigh - and just to complicate things a bit more, we don't want to pull a new libvirt unless it also fixes https://bugzilla.redhat.com/show_bug.cgi?id=884957 , which was identified as another regression introduced by the fix for 882309.
Comment 13 Eric Blake 2012-12-18 17:51:32 EST
(In reply to comment #12)
> sigh - and just to complicate things a bit more, we don't want to pull a new
> libvirt unless it also fixes
> https://bugzilla.redhat.com/show_bug.cgi?id=884957 , which was identified as
> another regression introduced by the fix for 882309.

No, bug 884957 does NOT affect Fedora.  It was a mis-type on my part when I was mentioning that the fix for bug 882309 introduced THIS bug as a regression.
Comment 14 Adam Williamson 2012-12-18 19:37:23 EST
ah, OK. that simplifies things a bit. i think we can just say 'we'll pull 0.10.2.2-3 as the fix for 882309 so it doesn't regress anything'.
Comment 15 Fedora Update System 2012-12-20 00:37:56 EST
libvirt-0.10.2.2-3.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

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