Red Hat Bugzilla – Bug 886663
libvirt-launched dnsmasq listens on localhost when it shouldn't
Last modified: 2014-06-18 03:42:56 EDT
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?
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.
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
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
...so if you don't include --except-interface=lo then it will the loopback automatically. Seems like a mis-feature to me, but whatever... ;)
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.
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 :-(
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)
Fix posted upstream. Waiting for ACK:
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.
libvirt-0.10.2.2-2.fc18 has been submitted as an update for Fedora 18.
libvirt-0.10.2.2-3.fc18 has been submitted as an update for Fedora 18.
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.
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.
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.
(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.
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'.
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.