|Summary:||CVE-2018-14636 openstack-neutron: eavesdropping private traffic due to trunk ports after live migration|
|Product:||[Other] Security Response||Reporter:||Laura Pardo <lpardo>|
|Component:||vulnerability||Assignee:||Red Hat Product Security <security-response-team>|
|Status:||NEW ---||QA Contact:|
|Version:||unspecified||CC:||amuller, apevec, chrisw, dbecker, dmoppert, ebarrera, jjoyce, jpadman, jschluet, kbasil, lhh, lpeer, majopela, markmc, mburns, rbryant, sclewis, scohen, security-response-team, skaplons, slinaber, srevivo, tdecacqu|
|Fixed In Version:||openstack-neutron 184.108.40.206b2, openstack-neutron 12.0.3, openstack-neutron 11.0.5||Doc Type:||If docs needed, set a value|
Live-migrated instances are briefly able to inspect traffic for other instances on the same hypervisor. This brief window could be extended indefinitely if the instance's port is set administratively down prior to live-migration and kept down after the migration is complete. This is possible due to the Open vSwitch integration bridge being connected to the instance during migration. When connected to the integration bridge, all traffic for instances using the same Open vSwitch instance would potentially be visible to the migrated guest, as the required Open vSwitch VLAN filters are only applied post-migration.
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:||1594978, 1614597, 1614600, 1678057, 1614596, 1614598, 1614599|
Description Laura Pardo 2018-06-25 21:57:09 UTC
A flaw was found in Openstack Neutron. During live-migration there is a small time window where the ports of instances are untagged. Instances have a port trunked to the integration bridge and receive 802.1Q tagged private traffic from other tenants. If the port is administratively down during live migration, the port will remain in trunk mode indefinitely. Traffic is possible between ports is that are administratively down, even between tenants self-service networks. This allows end users within their own private network to receive from, and send traffic to, other private networks on the same compute node. References: https://bugs.launchpad.net/neutron/+bug/1734320 https://bugs.launchpad.net/neutron/+bug/1767422 https://bugzilla.redhat.com/show_bug.cgi?id=1594825 Patch: https://git.openstack.org/cgit/openstack/neutron/commit/?id=88f5e11d8bf820b0124be0f6ec3c2d96011592d9
Comment 1 Laura Pardo 2018-06-25 21:57:46 UTC
Created openstack-neutron tracking bugs for this issue: Affects: openstack-rdo [bug 1594978]
Comment 2 Joshua Padman 2018-07-04 00:56:34 UTC
*** Bug 1594825 has been marked as a duplicate of this bug. ***
Comment 8 Miguel Angel Ajo 2018-08-10 14:58:49 UTC
Oh, the patches referenced on the bz are incorrect for this bz, also the 2nd launchpad ( https://bugs.launchpad.net/neutron/+bug/1767422 ). Those patches, and that second launchpad address the case when an agent (dhcp/l3/etc) get's a port plugged, but then the openvswitch-agent is not able to tag the port, it remains untagged, and it's a trunk port. But those patches *are not* addressing the instances themselves. This needs to be addressed in nova, or os-vif by plugging the port in vlan 4095, then, when neutron is ready will re-plug to the right vlan.
Comment 9 Slawek Kaplonski 2018-08-21 10:19:41 UTC
I checked that and it is like Miguel wrote in last comment. This issue isn't fixed in any of OSP versions yet. It should be fixed in os-vif module as this module is responsible for creating ports in openvswitch during booting/migrating instances. I proposed already such patch in upstream: https://review.openstack.org/594118
Comment 10 James Hebden 2018-08-28 04:57:07 UTC
Thanks Slawomir for the additional work to close the loop on this. We had included the fixes that had been provided upstream for information purposes, and as Miguel has noted in the tracker, additional patches to nova/os-vif are required to close this out fully. Can you confirm if the upstream neutron patches will also be applied? My understanding of the situation is that both this, and your additional os-vif patch are required to fully close this out.
Comment 11 Slawek Kaplonski 2018-08-28 07:35:17 UTC
Hi James. Unfortunately my patch proposed to os-vif will have to be modified and it will also require other patch in Neutron probably. We can't simply set this vlan tag always in os-vif as it breaks other Neutron backends (like networking-odl or dragonfly for example). I will work on that and propose patch to neutron and then modify this one for os-vif.
Comment 12 James Hebden 2018-09-09 22:31:03 UTC
Thanks Slawomir, for the clarification, that makes sense. Thanks for your work on this.
Comment 15 James Hebden 2018-09-24 01:35:56 UTC