Bug 1594977 (CVE-2018-14636)
| 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: | CLOSED WONTFIX | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | unspecified | CC: | apevec, chrisw, dmoppert, ebarrera, jjoyce, jpadman, jschluet, lhh, lpeer, majopela, markmc, mburns, osoukup, rbryant, sclewis, scohen, security-response-team, skaplons, slinaber, srevivo, tdecacqu |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | openstack-neutron 13.0.0.0b2, openstack-neutron 12.0.3, openstack-neutron 11.0.5 | Doc Type: | If docs needed, set a value |
| Doc Text: |
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.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-07-06 16:40:20 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1594978, 1614596, 1614597, 1614598, 1614599, 1614600, 1678057 | ||
| Bug Blocks: | 1594979 | ||
|
Description
Laura Pardo
2018-06-25 21:57:09 UTC
Created openstack-neutron tracking bugs for this issue: Affects: openstack-rdo [bug 1594978] *** Bug 1594825 has been marked as a duplicate of this bug. *** 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. 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 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. 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. Thanks Slawomir, for the clarification, that makes sense. Thanks for your work on this. This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2018-14636 |