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
This is fixed upstream now: http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=ae1232b298323dd7bef909426e2ebafa6bca9157
Statement: This issue affect Red Hat Enterprise Linux 6 and has been addressed via https://rhn.redhat.com/errata/RHBA-2012-0013.html. Red Hat Enterprise Linux 5 is not affected. The Red Hat Security Response Team has rated this issue as having low security impact. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.
Created libvirt tracking bugs for this issue Affects: fedora-16 [bug 766104]