This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
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...
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
impact=low,public=20111209,reported=2...
: Security
Depends On: 760442 766104 769674
Blocks: 889059
  Show dependency treegraph
 
Reported: 2011-12-09 14:25 EST by Vincent Danen
Modified: 2015-07-31 11:00 EDT (History)
7 users (show)

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


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:

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

http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=ae1232b298323dd7bef909426e2ebafa6bca9157
Comment 2 Vincent Danen 2011-12-10 00:38:18 EST
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/.
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.