yahoo-eng-team team mailing list archive

[Jeremy Stanley <fungi@xxxxxxxxxxx>]

It seems like we've got reasonable consensus that this is expected
behavior and have public documentation (at least in the Security Guide
as linked above, but likely also elsewhere), indicating that OpenStack
API servers on the whole do not make any attempt to mitigate excessively
rapid calls to expensive methods and so should be protected by a
separate filtering or throttling mechanism if they're deployed in an
environment where they're at risk of being overloaded.

I'll switch this public, treating as a class C1 report. If you or
someone else feels this scenario should be covered by a CVE then feel
free to request one from MITRE or another CNA, but please add it in a
follow-up comment on this bug if you do so that we won't end up with
multiple CVE assignments floating around for the same scenario. Thanks!

** 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.
- 
  I work as a penetration tester, in one of the last projects our team
  encountered a problem in openstack, We are not sure whether to consider
  this an openstack security vulnerability. Hope you could clarify things
  for us.
  
  We were testing race condition vulnerabilities on resources that have a limit per project. For example floating IP number.
  The idea is to make backend server recieve a lot of same requests at the same moment, and because the server has to proccess all of them simultaneously we could get a situation where the limits are not checked properly.
  
  Sending 500 requests (each in individual thread) directly to the Neutron
  API for allocation floating IPs resulted in exceeding the IP limit by 4
  times.
  
  Request example:
  
  POST /v2.0/floatingips HTTP/1.1
  Host: ...
  X-Auth-Token: ...
  Content-Type: application/json
  Content-Length: 103
  
  {
      "floatingip": {
          "floating_network_id": "..."
      }
  }
  
  Is it a known openstack behavior or is it more like a hardware problem?

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

Title:
  Race condition while allocating floating IPs

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

Bug description:
  I work as a penetration tester, in one of the last projects our team
  encountered a problem in openstack, We are not sure whether to
  consider this an openstack security vulnerability. Hope you could
  clarify things for us.

  We were testing race condition vulnerabilities on resources that have a limit per project. For example floating IP number.
  The idea is to make backend server recieve a lot of same requests at the same moment, and because the server has to proccess all of them simultaneously we could get a situation where the limits are not checked properly.

  Sending 500 requests (each in individual thread) directly to the
  Neutron API for allocation floating IPs resulted in exceeding the IP
  limit by 4 times.

  Request example:

  POST /v2.0/floatingips HTTP/1.1
  Host: ...
  X-Auth-Token: ...
  Content-Type: application/json
  Content-Length: 103

  {
      "floatingip": {
          "floating_network_id": "..."
      }
  }

  Is it a known openstack behavior or is it more like a hardware
  problem?

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