Bug 765964 (CVE-2011-4600)

It was reported [1] that libvirt 0.9.4, if a libvirt network with "forward mode" set to "bridge" is defined and started, and libvirtd is subequently restarted, then it will insert the following iptables rules based on the bridge (assuming the bridge name is br3):

-A INPUT -i br3 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i br3 -p tcp -m tcp --dport 53 -c -j ACCEPT
-A INPUT -i br3 -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -i br3 -p tcp -m tcp --dport 67 -j ACCEPT
-A FORWARD -i br3 -o br3 -j ACCEPT
-A FORWARD -o br3 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i br3 -j REJECT --reject-with icmp-port-unreachable

An example libvirt configuration:

<network>
<name>host-bridge-net</name>
<forward mode='bridge'/>
<bridge name='br3' />
</network>

The iptables rules should only be added for libvirt-managed networks, which are never directly connected to a physical interface.  A libvirt-managed network would be a network with a forward-mode of "nat", "route", or one with no forward mode at all (an isolated network).

As a result of the additional rules, if another DNS or DHCP server were running
on the host, it could allow external access to those services if other firewall
rules are preventing access to those ports.  It is unlikely that a system would
have a DHCP server running in such a way where it was not meant to listen to an
external interface, however it is possible that for DNS, iptables rules may be
limiting access to TCP/UDP ports 53 in order to restrict access to DNS.  The
iptables rules that libvirtd would add here could subvert those settings,
giving unintended access.

Only a privileged administrator would be able to make the necessary configuration changes where this might happen.  It also requires that libvirtd is restarted after this configuration change is made.  On subsequent reboots, the iptables rules will only be added if libvirtd is restarted post-boot (so the change does not persist across reboots unless libvirtd is restarted *after* the system boots). This flaw is new in libvirt 0.9.4; previous versions are not affected by this flaw; this only affects Red Hat Enterprise Linux 6.2 and Fedora 16.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=760442