On 11/21/2012 09:55 PM, Laine Stump wrote:
This bug resolves CVE-2012-3411, which is described in the following
bugzilla report:
https://bugzilla.redhat.com/show_bug.cgi?id=833033
The following report is specifically for libvirt on Fedora:
https://bugzilla.redhat.com/show_bug.cgi?id=874702
In short, a dnsmasq instance run with the intention of listening for
DHCP/DNS requests only on a libvirt virtual network (which is
constructed using a Linux host bridge) would also answer queries sent
from outside the virtualization host.
This patch takes advantage of a new dnsmasq option "--bind-dynamic",
which will cause the listening socket to be setup such that it will
only receive those requests that actually come in via the bridge
interface. In order for this behavior to actually occur, not only must
"--bind-interfaces" be replaced with "--bind-dynamic", but also all
"--listen-address" options must be replaced with a single
"--interface" option. Fully:
--bind-interfaces --except-interface lo --listen-address x.x.x.x ...
(with --listen-address possibly repeated) is replaced with:
--bind-dynamic --interface virbrX
I have some questions about this change.
1. If I correctly understand the problem being addressed (not a given),
a dnsmasq instance providing a dns service to a virtual network
interface was responding to queries on other network interfaces (virtual
or real). Obviously (to me) this is not desired and should be
considered a security problem. This series of patches is intended to
address this problem while continuing to support older versions of
dnsmasq which do not support bind-dynamic.
[If I understand correctly then, while this is a problem for IPv4, it
could be even more critical for IPv6.]
2. I assume that this change still supports queries originating on the
virtualization host and directed to the virtual network interface.
3. I assume that dnsmasq's support of DHCP continues as before.
[I will be implementing this update and testing it over the next couple
of days. For one thing, I need to integrate my DHCPv6, etc. patches
with this. For one thing, I need to pick up the dnsmasq version
implemented by this patch.]
4. What about the situation where an "Internet publically available"
service is implemented on a virtual (guest) system. I assume that the
dnsmasq instance for the virtual network interface will not be directly
available for external queries. How about if the virtualization host is
running yet another instance of dnsmasq (not started by libvirt) which
forwards queries to the dnsmasq instance started by libvirt (the query
would be sent to an address on the virtual network interface).
5. I assume dnsmasq will respond to queries on any IPv4 or IPv6
(gateway) address defined on a virtual network interface.
6. I assume that, if no IPv4 or IPv6 (gateway) addresses are defined on
an interface, dnsmasq will not be started for that interface.
7. Are there any conditions where bind-interface would still be
preferable to bind-dynamic? [Maybe I need to ask Simon Kelley this
question.]
Comment: You sure did put a lot of effort into making sure that libvirt
would still work with older versions of dnsmasq which did not support
bind-dynamic.
Gene
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list