yahoo-eng-team team mailing list archive

[Jeremy Stanley <fungi@xxxxxxxxxxx>]

** 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. This
- embargo shall not extend past 2020-05-27 and will be made
- public by or on that date if no fix is identified.
- 
  Tested with Train release, by quick code check it affects also at least
  Rocky, Stein and Ussuri (current master).
  
  The security issue is than one can access metadata of an arbitrary other instance if the following conditions are met (let's call the "other instance" a "victim", it can be in any other project not normally available to the attacker):
  1) Victim's port fixed IP address is known.
  2) Victim's port network ID is known.
  3) Attacker can use a network with access to l3 agent metadata proxy (i.e. can use routers) and deploy instances.
  
  The scenario is as follows:
  1) create a self-service network including the targeted address
  2) create an instance with the same fixed IP address
  3) create a router and wire it up with that network (other connections irrelevant)
  4) boot up the instance (make sure to drop the potential route to dhcp agent metadata proxy if used)
  5) run e.g.:
  curl -H "X-Neutron-Network-ID: $VICTIM_NET_ID" 169.254.169.254/openstack/latest/meta_data.json
  
  Observed behaviour:
  Normally-secret information disclosure.
  
  Expected behaviour:
  Proxy ignores (removes) that extra header and proceeds as if nothing happened (most expected)
  OR proxy returns an error (and logs it / sends a notification about it)
  OR proxy blocks the request and calls the police as you are a bad boy :-) (least expected... but nice)
  
  Initial code analysis:
  
  1) the haproxy config is inadequate:
  https://opendev.org/openstack/neutron/src/commit/6b9765c991da8731fe39f7e7eed1ed6e2bca231a/neutron/agent/metadata/driver.py#L68
  ^ this should replace all current headers in the current trust model
  
  2) the reason this works with l3 agent (and so far not with dhcp agent unless there is some other general header exploit in the stack) are the following lines:
  https://opendev.org/openstack/neutron/src/commit/6b9765c991da8731fe39f7e7eed1ed6e2bca231a/neutron/agent/metadata/agent.py#L146-L152

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

Title:
  l3 agent metadata proxy allows access to metadata from any available
  network

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

Bug description:
  Tested with Train release, by quick code check it affects also at
  least Rocky, Stein and Ussuri (current master).

  The security issue is than one can access metadata of an arbitrary other instance if the following conditions are met (let's call the "other instance" a "victim", it can be in any other project not normally available to the attacker):
  1) Victim's port fixed IP address is known.
  2) Victim's port network ID is known.
  3) Attacker can use a network with access to l3 agent metadata proxy (i.e. can use routers) and deploy instances.

  The scenario is as follows:
  1) create a self-service network including the targeted address
  2) create an instance with the same fixed IP address
  3) create a router and wire it up with that network (other connections irrelevant)
  4) boot up the instance (make sure to drop the potential route to dhcp agent metadata proxy if used)
  5) run e.g.:
  curl -H "X-Neutron-Network-ID: $VICTIM_NET_ID" 169.254.169.254/openstack/latest/meta_data.json

  Observed behaviour:
  Normally-secret information disclosure.

  Expected behaviour:
  Proxy ignores (removes) that extra header and proceeds as if nothing happened (most expected)
  OR proxy returns an error (and logs it / sends a notification about it)
  OR proxy blocks the request and calls the police as you are a bad boy :-) (least expected... but nice)

  Initial code analysis:

  1) the haproxy config is inadequate:
  https://opendev.org/openstack/neutron/src/commit/6b9765c991da8731fe39f7e7eed1ed6e2bca231a/neutron/agent/metadata/driver.py#L68
  ^ this should replace all current headers in the current trust model

  2) the reason this works with l3 agent (and so far not with dhcp agent unless there is some other general header exploit in the stack) are the following lines:
  https://opendev.org/openstack/neutron/src/commit/6b9765c991da8731fe39f7e7eed1ed6e2bca231a/neutron/agent/metadata/agent.py#L146-L152

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