Bug 1594825

Summary: fix for security issue on neutron to downstream (LP#1734320 Eavesdropping private traffic )
Product: Red Hat OpenStack Reporter: Eduard Barrera <ebarrera>
Component: openstack-neutronAssignee: Assaf Muller <amuller>
Status: CLOSED DUPLICATE QA Contact: Toni Freger <tfreger>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 12.0 (Pike)CC: amuller, chrisw, jpadman, nyechiel, security-response-team, srevivo
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-07-04 00:56:34 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Eduard Barrera 2018-06-25 13:44:04 UTC
Description of problem:

There is concern amoung customer about this security issue reported upstream[1] that is public and easy to exploit. Now the bug reported (our customer) is requesting help to us in order to fix the issue, since it has been running for long and now is public.

A time ago we've filled in a security bug on launchpad. This bug is causing to be able to sniff other customer traffic from an instance that is located on a same compute node. Link to the bug: https://bugs.launchpad.net/neutron/+bug/1734320

Tldr; How to reproduce the security bug:
Spawn an instance with two nics:
openstack server create --nic net-id=<net-uuid1> --nic net-id=<net-uuid2> --image <image_id> --flavor <flavor_id> instance_temp

tcpdump on second nic in instance:
[root@instance_temp]$ tcpdump -eeeni eth1
      Port "qvoa848520b-08"
          tag: 4095
          Interface "qvoa848520b-08"

force port-down on second nic:
neutron port-update <port-id of second nic> --admin-state-up False

Verify port gets tagged with vlan 4095 on compute node:
compute# ovs-vsctl show | grep -A3 qvo<part of port-id>

Now resize(can be done as user) or live-migrate(require admin) the instance:
nova live-migration <instanceid>

Now port is untagged(tag 4095 is missing):
compute2# ovs-vsctl show | grep -A3 qvo<part of port-id>
      Port "qvoa848520b-08"
          Interface "qvoa848520b-08"

Now traffic of all other self-service networks present on compute2 can be sniffed from instance_temp

[root@instance_temp] tcpdump -eenni eth1
13:14:31.748266 fa:16:3e:6a:17:38 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 10, p 0, ethertype ARP, Request who-has tell, length 28
13:14:31.804573 fa:16:3e:e8:a2:d2 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 33, p 0, ethertype ARP, Request who-has tell, length 28
13:14:31.810482 fa:16:3e:95:ca:3a > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 33, p 0, ethertype ARP, Request who-has tell, length 28

We've already filled a bug and it is confirmed(see link above). Unfortunately we don't have the knowledge of creating a patch and writing unit tests. The bug is open for quite some time and it is difficult to fix since it requires interaction with multiple projects. Is it possible that RH can acquire some resources for this serious security bug?

What is the plan for this issue? Can we help customer with his request ?


Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:

Actual results:

Expected results:

Additional info:

Comment 3 Joshua Padman 2018-07-04 00:56:34 UTC
Product security are treating this as a security vulnerability and have created a special flaw bug for tracking it (bz 1594977). Please use this new bug for conversation moving forward.

Thank you for the report, in the interest of transparency this is being opened to the public.

*** This bug has been marked as a duplicate of bug 1594977 ***