Bug 765964 - (CVE-2011-4600) CVE-2011-4600 libvirt: unintended firewall port exposure after restarting libvirtd when defining a bridged forward-mode network
CVE-2011-4600 libvirt: unintended firewall port exposure after restarting lib...
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
: Security
Depends On: 760442 766104 769674
Blocks: 889059
  Show dependency treegraph
Reported: 2011-12-09 14:25 EST by Vincent Danen
Modified: 2016-11-08 11:05 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-04-24 08:46:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Vincent Danen 2011-12-09 14:25:53 EST
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:

<forward mode='bridge'/>
<bridge name='br3' />

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
Comment 1 Vincent Danen 2011-12-10 00:37:36 EST
This is fixed upstream now:

Comment 2 Vincent Danen 2011-12-10 00:38:18 EST

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/.
Comment 4 Vincent Danen 2011-12-10 00:39:36 EST
Created libvirt tracking bugs for this issue

Affects: fedora-16 [bug 766104]

Note You need to log in before you can comment on or make changes to this bug.