yahoo-eng-team team mailing list archive

[Jeremy Stanley <fungi@xxxxxxxxxxx>]

Thanks everyone for the prompt analysis. I've triaged this as a class B2
port per the OpenStack VMT taxonomy: https://security.openstack.org/vmt-
process.html#incident-report-taxonomy

** Information type changed from Private Security to Public

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

** Also affects: ossn
   Importance: Undecided
       Status: New

** Description changed:

- 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.
- 
  On an openstack-ansible / newton setup with linuxbridge, a customer ran:
  
  neutron port-update $port-uuid --allowed-address-pairs type=dict
  list=true ip_address=0.0.0.0/0
  
  to bypass the ip source restriction (pfsense router and had to route
  packets).
  
  The impact of running the above, was an allow all rule was added to all
  ports in the network, bypassing all security groups.
  
  The iptables rule:
  
   905K   55M RETURN     all  --  *      *       0.0.0.0/0
  0.0.0.0/0            match-set NIPv44046d62c-59c8-4fd0-a547- src
  
  used on all ports, now triggers as:
  
  0.0.0.0/1
  128.0.0.0/1
  
  was added to the ipset NIPv44046d62c-59c8-4fd0-a547 (verified by looking
  at the ipset on the nova hosts). Removing the two lines from the ipset
  restored all security groups.
  
  Expected result was to remove ip filtering on the single port.
  
  This sounds similar to:
  
  https://bugs.launchpad.net/neutron/+bug/1461054
  
  but is marked fixed long ago.
  
  I've marked this as a security bug as a change to a single port can
  bypass other ports security groups.

** 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/1793029

Title:
  adding 0.0.0.0/0 address pair to a port  bypasses all other vm
  security groups

Status in neutron:
  New
Status in OpenStack Security Advisory:
  Won't Fix
Status in OpenStack Security Notes:
  New

Bug description:
  On an openstack-ansible / newton setup with linuxbridge, a customer
  ran:

  neutron port-update $port-uuid --allowed-address-pairs type=dict
  list=true ip_address=0.0.0.0/0

  to bypass the ip source restriction (pfsense router and had to route
  packets).

  The impact of running the above, was an allow all rule was added to
  all ports in the network, bypassing all security groups.

  The iptables rule:

   905K   55M RETURN     all  --  *      *       0.0.0.0/0
  0.0.0.0/0            match-set NIPv44046d62c-59c8-4fd0-a547- src

  used on all ports, now triggers as:

  0.0.0.0/1
  128.0.0.0/1

  was added to the ipset NIPv44046d62c-59c8-4fd0-a547 (verified by
  looking at the ipset on the nova hosts). Removing the two lines from
  the ipset restored all security groups.

  Expected result was to remove ip filtering on the single port.

  This sounds similar to:

  https://bugs.launchpad.net/neutron/+bug/1461054

  but is marked fixed long ago.

  I've marked this as a security bug as a change to a single port can
  bypass other ports security groups.

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