| 2020-02-05 18:00:04 |
Rustam Komildzhonov |
bug |
|
|
added bug |
| 2020-02-05 19:44:59 |
Jeremy Stanley |
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? |
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? |
|
| 2020-02-05 19:45:06 |
Jeremy Stanley |
bug task added |
|
ossa |
|
| 2020-02-05 19:45:12 |
Jeremy Stanley |
ossa: status |
New |
Incomplete |
|
| 2020-02-05 19:45:28 |
Jeremy Stanley |
bug |
|
|
added subscriber Neutron Core Security reviewers |
| 2020-02-07 10:43:38 |
Rustam Komildzhonov |
bug |
|
|
added subscriber Mikhail Abramov |
| 2020-02-07 10:50:24 |
Rustam Komildzhonov |
bug |
|
|
added subscriber Mikhail |
| 2020-02-17 20:37:20 |
Jeremy Stanley |
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.
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? |
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? |
|
| 2020-02-17 20:37:31 |
Jeremy Stanley |
information type |
Private Security |
Public |
|
| 2020-02-17 20:37:50 |
Jeremy Stanley |
ossa: status |
Incomplete |
Won't Fix |
|
| 2020-02-17 20:38:03 |
Jeremy Stanley |
tags |
|
security |
|
