yahoo-eng-team team mailing list archive

[Jeremy Stanley <fungi@xxxxxxxxxxx>]

Given that this hasn't appeared in any official release yet, the risk
exposed by it is low, there's an assertion that it's probably working as
intended and a need has been expressed to bring additional teams into
the discussion... I'm going to switch this to Public for now.

If the issue is determined to be an actual defect and vulnerability and
somehow isn't fixed before release, we can revisit issuing an advisory
once it gets fixed but I see no reason to slow down this evaluation with
our embargo process.

** Information type changed from Private Security to Public

** Changed in: ossa
       Status: Incomplete => Won't Fix

** Tags added: security

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1704398

Title:
  Inheriting trunk subport segmentation details leaks information

Status in neutron:
  Incomplete
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  This issue is being treated as a potential security risk under
  embargo. Please do not make any public mention of embargoed (private)
  security vulnerabilities before their coordinated publication by the
  OpenStack Vulnerability Management Team in the form of an official
  OpenStack Security Advisory. This includes discussion of the bug or
  associated fixes in public forums such as mailing lists, code review
  systems and bug trackers. Please also avoid private disclosure to
  other individuals not already approved for access to this information,
  and provide this same reminder to those who are made aware of the
  issue prior to publication. All discussion should remain confined to
  this private bug report, and any proposed fixes should be added to the
  bug as attachments.

  The following information is discoverable for non-admin users of neutron despite the policy:
  * the segmentation type and id of all vlan based networks
  * the segmentation type of all non-vlan based networks

  Reproduction:

  configuration)

  [[local|localrc]]
  enable_plugin neutron ...
  enable_service q-trunk

  versions)

  devstack b79531a9f96736225a8991052a0be5767c217377
  neutron 3a894d0b9e8e71bf7ee7e42350685065df5a8b3c

  1) for vlan networks

  source openrc admin demo
  openstack network create net0 --provider-network-type vlan --provider-physical-network test --provider-segment 100
  openstack network create net1 --provider-network-type vlan --provider-physical-network test --provider-segment 101

  source openrc demo demo
  openstack port create port0 --network net0
  openstack port create port1 --network net1
  openstack network trunk create trunk0 --parent-port port0
  openstack network trunk set trunk0 --subport port=port1,segmentation-type=inherit

  # demo user has no right to see segmentation type and id of vlan provider net
  openstack network show net1
  # but both the type and id are available in the subport list
  openstack network subport list --trunk trunk0

  2) for other network types

  source openrc admin demo
  openstack network create net0
  openstack network create net1

  source openrc demo demo
  openstack port create port0 --network net0
  openstack port create port1 --network net1
  openstack network trunk create trunk0 --parent-port port0
  # the type of net1 comes back in the error message (in my environment 'vxlan')
  openstack network trunk set trunk0 --subport port=port1,segmentation-type=inherit

  While according to the default policy this information should be admin-only. See around here:
  https://github.com/openstack/neutron/blob/93390579da5d044a4e725faafd2b1f1d2d072a2a/etc/policy.json#L45

  This behavior was introduced in response to this rfe:
  https://bugs.launchpad.net/neutron/+bug/1648129

  Actually sharing this information is the point of the rfe.

  IIRC the concern about the information leak was even raised during a
  review, but it seems it went unaddressed. (Yep, I found the comment
  again: https://review.openstack.org/436756 comment at 03-07 21:12)

  I'm not sure if the segmentation details should be considered
  sensitive information or not. But the current behavior (admin-only
  here, not admin-only there) is clearly inconsistent.

  We could probably solve this by just synchronizing the default
  policies of provider network get operation and subport segmentation
  detail inheritance.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1704398/+subscriptions