network: use dnsmasq --bind-dynamic when available CVE-2012-3411
authorLaine Stump <laine@laine.org>
Thu, 22 Nov 2012 02:21:02 +0000 (21:21 -0500)
committerLaine Stump <laine@laine.org>
Thu, 29 Nov 2012 20:02:39 +0000 (15:02 -0500)
commit753ff83a50263d6975f88d6605d4b5ddfcc97560
tree5c47f4dcc19971104974efd34c4903fbb731f614
parentbf402e77b6d53a4e569b3aa76aef9c7d589c0cf2
network: use dnsmasq --bind-dynamic when available

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

Of course libvirt can't use this new option if the host's dnsmasq
doesn't have it, but we still want libvirt to function (because the
great majority of libvirt installations, which only have mode='nat'
networks using RFC1918 private address ranges (e.g. 192.168.122.0/24),
are immune to this vulnerability from anywhere beyond the local subnet
of the host), so we use the new dnsmasqCaps API to check if dnsmasq
supports the new option and, if not, we use the "old" option style
instead. In order to assure that this permissiveness doesn't lead to a
vulnerable system, we do check for non-private addresses in this case,
and refuse to start the network if both a) we are using the old-style
options, and b) the network has a publicly routable IP
address. Hopefully this will provide the proper balance of not being
disruptive to those not practically affected, and making sure that
those who *are* affected get their dnsmasq upgraded.

(--bind-dynamic was added to dnsmasq in upstream commit
54dd393f3938fc0c19088fbd319b95e37d81a2b0, which was included in
dnsmasq-2.63)
src/network/bridge_driver.c
tests/networkxml2argvdata/isolated-network.argv
tests/networkxml2argvdata/nat-network-dns-hosts.argv
tests/networkxml2argvdata/nat-network-dns-srv-record-minimal.argv
tests/networkxml2argvdata/nat-network-dns-srv-record-minimal.xml
tests/networkxml2argvdata/nat-network-dns-srv-record.argv
tests/networkxml2argvdata/nat-network-dns-txt-record.argv
tests/networkxml2argvdata/nat-network.argv
tests/networkxml2argvdata/netboot-network.argv
tests/networkxml2argvdata/netboot-proxy-network.argv
tests/networkxml2argvdata/routed-network.argv