After reading through, it seems this flaw is CVE-worthy (vs an OSSN / hardening). The main security point is that a user can retrieve their own volume's connection information and then use it to access another user's volume/info.
Per Brian's draft OSSN notes: "When using Cinder with the Dell EMC ScaleIO or VxFlex OS backend storage driver, credentials for the entire backend are exposed in the ``connection_info`` element in all Block Storage v3 Attachments API calls containing that element. This enables an end user to create a volume, make an API call to show the attachment detail information, and retrieve a username and password that may be used to connect to another user's volume. Additionally, these credentials are valid for the ScaleIO or VxFlex OS Management API, should an attacker discover the Management API endpoint."
Will the OpenStack VMT move this to a CVE (OSSA)? Or is there a reason to see/keep this flaw at the hardening level?
After reading through, it seems this flaw is CVE-worthy (vs an OSSN / hardening). The main security point is that a user can retrieve their own volume's connection information and then use it to access another user's volume/info.
Per Brian's draft OSSN notes: "When using Cinder with the Dell EMC ScaleIO or VxFlex OS backend storage driver, credentials for the entire backend are exposed in the ``connection_info`` element in all Block Storage v3 Attachments API calls containing that element. This enables an end user to create a volume, make an API call to show the attachment detail information, and retrieve a username and password that may be used to connect to another user's volume. Additionally, these credentials are valid for the ScaleIO or VxFlex OS Management API, should an attacker discover the Management API endpoint."
Will the OpenStack VMT move this to a CVE (OSSA)? Or is there a reason to see/keep this flaw at the hardening level?