- OpenStack-announce - lists.openstack.org

[OSSA-2020-007] Blazar: Remote code execution in blazar-dashboard (CVE-2020-26943)
by Pierre Riteau 17 Oct '20

17 Oct '20

======================================================== OSSA-2020-007: Remote code execution in blazar-dashboard ======================================================== :Date: October 12, 2020 :CVE: CVE-2020-26943 Affects ~~~~~~~ - Blazar-dashboard: <1.3.1, ==2.0.0, ==3.0.0 Description ~~~~~~~~~~~ Lukas Euler (Positive Security) reported a vulnerability in blazar-dashboard. A user allowed to access the Blazar dashboard in Horizon may trigger code execution on the Horizon host as the user the Horizon service runs under. This may result in Horizon host unauthorized access and further compromise of the Horizon service. All setups using the Horizon dashboard with the blazar-dashboard plugin are affected. Patches ~~~~~~~ - https://review.opendev.org/755814 (Stein) - https://review.opendev.org/755813 (Train) - https://review.opendev.org/755812 (Ussuri) - https://review.opendev.org/756064 (Victoria) - https://review.opendev.org/755810 (Wallaby) Credits ~~~~~~~ - Lukas Euler from Positive Security (CVE-2020-26943) References ~~~~~~~~~~ - https://launchpad.net/bugs/1895688 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-26943

1 0

OpenStack Victoria is officially released!
by Sean McGinnis 14 Oct '20

14 Oct '20

Hello OpenStack community, I'm excited to announce the final releases for the components of OpenStack Victoria, which concludes the Victoria development cycle. You will find a complete list of all components, their latest versions, and links to individual project release notes documents listed on the new release site. https://releases.openstack.org/victoria/ Congratulations to all of the teams who have contributed to this release! Our next production cycle, Wallaby, has already started. We will virtually meet October 26-30, 2020, for the Wallaby Project Teams Gathering. More details can be found on the PTG site: https://www.openstack.org/ptg Thanks, Sean McGinnis and the Release Management team

1 0

[all][elections][tc] Technical Committee Election Results
by Jeremy Stanley 14 Oct '20

14 Oct '20

Please join me in congratulating the 4 newly elected members of the Technical Committe (TC). Dan Smith Ghanshyam Mann (gmann) Jay Bryant (jungleboyj) Kendall Nelson (diablo_rojo) Full results: https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_f3d92f86f4254553 Election process details and results are also available here: https://governance.openstack.org/election/ Thank you to all of the candidates, having a good group of candidates helps engage the community in our democratic process. Thank you to all who voted and who encouraged others to vote. We need to ensure your voice is heard. Thank you for another great round. -- Jeremy Stanley on behalf of the OpenStack Technical Election Officials

1 0

[all][elections][ptl] Project Team Lead Election Conclusion and Results
by Jeremy Stanley 14 Oct '20

14 Oct '20

Thank you to the electorate, to all those who voted and to all candidates who put their name forward for Project Team Lead (PTL) in this election. A healthy, open process breeds trust in our decision making capability thank you to all those who make this process possible. Now for the results of the PTL election process, please join me in extending congratulations to the following PTLs: * Adjutant : Adrian Turjak * Barbican : Douglas Mendizábal * Blazar : Pierre Riteau * Cinder : Brian Rosmaita * Cyborg : Yumeng Bao * Designate : Michael Johnson * Ec2 Api : Andrey Pavlov * Freezer : cai hui * Glance : Abhishek Kekane * Heat : Rico Lin * Horizon : Ivan Kolodyazhny * Ironic : Julia Kreger * Keystone : Kristi Nikolla * Kolla : Mark Goddard * Kuryr : Maysa de Macedo Souza * Magnum : Spyros Trigazis * Manila : Goutham Pacha Ravi * Masakari : Radosław Piliszek * Mistral : Renat Akhmerov * Monasca : Martin Chacon Piza * Murano : Rong Zhu * Neutron : Sławek Kapłoński * Nova : Balazs Gibizer * Openstack Chef : Lance Albertson * OpenStack Helm : Gage Hugo * OpenStackAnsible : Dmitriy Rabotyagov * OpenStackSDK : Artem Goncharov * Puppet OpenStack : Shengping Zhong * Quality Assurance : Masayuki Igawa * Rally : Andrey Kurilin * Release Management : Hervé Beraud * Requirements : Matthew Thode * Sahara : Jeremy Freudberg * Solum : Rong Zhu * Storlets : Takashi Kajinami * Swift : Tim Burke * Tacker : Yasufumi Ogawa * Telemetry : Matthias Runge * Tripleo : Marios Andreou * Trove : Lingxian Kong * Vitrage : Eyal Bar-Ilan * Watcher : canwei li * Winstackers : Lucian Petrut * Zaqar : wang hao * Zun : Feng Shengqin Elections: * Telemetry: https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_2428aa2ecc67cc17 Election process details and results are also available here: https://governance.openstack.org/election/ Thank you to all involved in the PTL election process, -- Jeremy Stanley on behalf of the OpenStack Technical Election Officials

1 0

[OSSA-2020-006] Nova: Live migration fails to update persistent domain XML (CVE-2020-17376)
by Jeremy Stanley 26 Aug '20

26 Aug '20

=================================================================== OSSA-2020-006: Live migration fails to update persistent domain XML =================================================================== :Date: August 25, 2020 :CVE: CVE-2020-17376 Affects ~~~~~~~ - Nova: <19.3.1, >=20.0.0 <20.3.1, ==21.0.0 Description ~~~~~~~~~~~ Tadayoshi Hosoya (NEC) and Lee Yarwood (Red Hat) reported a vulnerability in Nova live migration. By performing a soft reboot of an instance which has previously undergone live migration, a user may gain access to destination host devices that share the same paths as host devices previously referenced by the virtual machine on the source. This can include block devices that map to different Cinder volumes on the destination than the source. The risk is increased significantly in non-default configurations allowing untrusted users to initiate live migrations, so administrators may consider temporarily disabling this in policy if they cannot upgrade immediately. This only impacts deployments where users are allowed to perform soft reboots of server instances; it is recommended to disable soft reboots in policy (only allowing hard reboots) until the fix can be applied. Patches ~~~~~~~ - https://review.opendev.org/747978 (Pike) - https://review.opendev.org/747976 (Queens) - https://review.opendev.org/747975 (Rocky) - https://review.opendev.org/747974 (Stein) - https://review.opendev.org/747973 (Train) - https://review.opendev.org/747972 (Ussuri) - https://review.opendev.org/747969 (Victoria) Credits ~~~~~~~ - Tadayoshi Hosoya from NEC (CVE-2020-17376) - Lee Yarwood from Red Hat (CVE-2020-17376) References ~~~~~~~~~~ - https://launchpad.net/bugs/1890501 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-17376 Notes ~~~~~ - The stable/rocky, stable/queens, and stable/pike branches are under extended maintenance and will receive no new point releases, but patches for them are provided as a courtesy. -- Jeremy Stanley OpenStack Vulnerability Management Team

1 0

[OSSN-0086] erratum: Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure
by Brian Rosmaita 19 Jun '20

19 Jun '20

As you may recall, the fix for this issue required patches for both Cinder and the os-brick library. The original patch for os-brick contained a flaw [0] that prevented the scaleio connector from operating when run under Python 2.7. Thus for OpenStack releases supporting Python 2.7 (that is, Train and earlier), a second os-brick patch is required and is listed below. (The Cinder and first os-brick patch are unchanged, but are listed below for completeness). [0] https://bugs.launchpad.net/os-brick/+bug/1883654 #### Patches #### Queens * cinder: https://review.opendev.org/733110 * os-brick: https://review.opendev.org/733104 and https://review.opendev.org/736749 Rocky * cinder: https://review.opendev.org/733109 * os-brick: https://review.opendev.org/733103 and https://review.opendev.org/736415 Stein * cinder: https://review.opendev.org/733108 * os-brick: https://review.opendev.org/733102 and https://review.opendev.org/736395 Train * cinder: https://review.opendev.org/733107 * os-brick: https://review.opendev.org/733100 and https://review.opendev.org/735989 Updated releases of os-brick incorporating the second patch are now available: Stein: os-brick 2.8.6 Train: os-brick 2.10.4 Point releases of cinder for Stein and Train will be made as soon as possible. These will be: Stein: cinder 14.1.1, requires os-brick 2.8.6 Train: cinder 15.2.1, requires os-brick 2.10.4 ### Contacts / References ### Author: Brian Rosmaita, Red Hat OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0086 Original LaunchPad Bug : https://bugs.launchpad.net/cinder/+bug/1823200 Mailing List : [Security] tag on openstack-discuss(a)lists.openstack.org OpenStack Security Project : https://launchpad.net/~openstack-ossg CVE: CVE-2020-10755

1 0

[OSSN-0086] Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure
by Brian Rosmaita 04 Jun '20

04 Jun '20

Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure --- ### Summary ### This vulnerability is present when using Cinder with a Dell EMC ScaleIO or VxFlex OS storage backend. Note: The Dell EMC "ScaleIO" driver was rebranded as "VxFlex OS" in the Train release. ### Affected Services / Software ### Cinder / Ocata, Pike, Queens, Rocky, Stein, Train, Ussuri This vulnerability applies only when using a Dell EMC ScaleIO/VxFlex OS Backend with Cinder. Other drivers are not impacted. ### Discussion ### 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. This issue was reported by David Hill and Eric Harney of Red Hat. ### Recommended Actions ### Remediation of this issue consists of the following: 1. Patching the ScaleIO or VxFlex OS Cinder driver so that it no longer provides the password to Cinder when a Block Storage v3 Attachments API response is constructed. 2. Patching the ScaleIO connector in the os-brick library so that it retrieves the password from a configuration file readable only by root. (Note: the connector was not rebranded; both ScaleIO and VxFlex OS backends use the 'scaleio' os-brick connector.) 3. Patching the ScaleIO os-brick privileged file that allows the scaleio connector to escalate privileges for specific operations; this is necessary to allow the connector process to access the configuration file that is readable only by root. 4. Deploying a configuration file containing the password (and replication password, if applicable) to all compute nodes, cinder nodes, and anywhere you would perform a volume attachment in your deployment. To refresh database information, all volumes should be detached and reattached. Because this remediation consists of deploying credentials in a root-readable-only file, it is not suitable for the use case of attaching a volume to a bare metal host. Thus, the Dell EMC ScaleIO/VxFlex OS storage backend for Cinder is *not recommended* for use with bare metal hosts. Note: The Ocata, Pike, Queens, and Rocky branches of OpenStack are in the Extended Maintenance phase. Point releases are no longer made from these branches and security patches are produced only on a reasonable effort basis. Patches for Queens and Rocky are provided as a courtesy. Patches for Ocata and Pike are not available. #### Patches #### Both cinder and os-brick must be patched. Documentation is provided as part of the cinder patch concerning the new configuration file that must be deployed to all compute nodes, cinder nodes, and anywhere you would perform a volume attachment in your deployment. Queens * cinder: https://review.opendev.org/733110 * os-brick: https://review.opendev.org/733104 Rocky * cinder: https://review.opendev.org/733109 * os-brick: https://review.opendev.org/733103 Stein * cinder: https://review.opendev.org/733108 * os-brick: https://review.opendev.org/733102 Train * cinder: https://review.opendev.org/733107 * os-brick: https://review.opendev.org/733100 Ussuri * cinder: https://review.opendev.org/733106 * os-brick: https://review.opendev.org/733099 Alternatively, point releases for Stein, Train, and Ussuri will be made as soon as possible. These will be: Stein: cinder 14.0.5, requires os-brick 2.8.5 Train: cinder 15.1.1, requires os-brick 2.10.3 Ussuri: cinder 16.0.1, requires os-brick 3.0.2 ### Contacts / References ### Author: Brian Rosmaita, Red Hat This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0086 Original LaunchPad Bug : https://bugs.launchpad.net/cinder/+bug/1823200 Mailing List : [Security] tag on openstack-discuss(a)lists.openstack.org OpenStack Security Project : https://launchpad.net/~openstack-ossg CVE: CVE-2020-10755

1 0

OpenStack Ussuri is officially released!
by Sean McGinnis 13 May '20

13 May '20

Hello OpenStack community, I'm excited to announce the final releases for the components of OpenStack Ussuri, which concludes the Ussuri development cycle. You will find a complete list of all components, their latest versions, and links to individual project release notes documents listed on the new release site. https://releases.openstack.org/ussuri/ Congratulations to all of the teams who have contributed to this release! Our next production cycle, Victoria, has already started. We will virtually meet June 1-5, 2020, for the Victoria Project Teams Gathering. More details can be found on the PTG site: https://www.openstack.org/ptg Thanks, Sean McGinnis and the Release Management team

1 0

[OSSA-2020-005] Keystone: OAuth1 request token authorize silently ignores roles parameter (CVE PENDING)
by Gage Hugo 08 May '20

08 May '20

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================== OSSA-2020-005: OAuth1 request token authorize silently ignores roles parameter ============================================================================== :Date: May 06, 2020 :CVE: Pending Affects ~~~~~~~ - - Keystone: <15.0.1, ==16.0.0 Description ~~~~~~~~~~~ kay reported a vulnerability in Keystone's OAuth1 Token API. The list of roles provided for an OAuth1 access token are ignored, so when an OAuth1 access token is used to request a keystone token, the keystone token will contain every role assignment the creator had for the project instead of the provided subset of roles. This results in the provided keystone token having more role assignments than the creator intended, possibly giving unintended escalated access. Patches ~~~~~~~ - - https://review.opendev.org/725894 (Rocky) - - https://review.opendev.org/725892 (Stein) - - https://review.opendev.org/725890 (Train) - - https://review.opendev.org/725887 (Ussuri) - - https://review.opendev.org/725885 (Victoria) Credits ~~~~~~~ - - kay (CVE Pending) References ~~~~~~~~~~ - - https://launchpad.net/bugs/1873290 - - http://cve.mitre.org/cgi-bin/cvename.cgi?name=Pending Notes ~~~~~ - - The stable/rocky branch is under extended maintenance and will receive no new point releases, but a patch for it is provided as a courtesy. -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEWa125cLHIuv6ekof56j9K3b+vREFAl6zFWsACgkQ56j9K3b+ vRFDnhAArgXdQUnCyckPQciBvxMxQvqhCEhzGH0aQNAmMLaImYUwFhFVVO0DlcNb kt/ynLQLdyi3YnCz1x4VhUXaCh4Rhi9pYkU4LKa/tvJj6anrCSLHmuDD52idkZeB sFslgkh/BGfdM4HcuPLhs4SSaZpI53ASitiOhyjBIN/DmpLUbZgmJ1iz3FfQ3cTB wtjYI4jGCCMq+4POSozWMzeYdL3JzR264jBCRrCw1ErIPjpF4KSOFaH5vqakBnzw Ot7KR7s7FmIwU7LhCuvjgLW3rxwE1g5bz+Qd/97rC1bTx/iPHklQjMP5SoGwmjta Kx1prUaQqFys5Bw93e0cj1Fwn0zNHUjqLs4LZscNbyGRyAZCPREeg2quwBxVUNk9 D6jxW3J2LYIu+ictVV5fnBQd4/+NtxM8ofLDM03QZouUpkNfCHAmW81BYqd2+Pii VbJi5Litz+DHLrAyh0O4zD/PBc5+5zxB2EXEDVEJitqaxQWfogJwJzGe89ULom0I VXMuYOvqaLV9f2JIG6SEBiKrfaUhSgoHTrmznt82KOlsOBMamQUaj5iTqDoDzPD2 LVB2WLABj1cFZsnTFAec1qKwEPXuT0p3Dsb7eyvwsq5aJYS5I2bjK6Q1WcCcqzJF 1b+v0iqW0Qu+Hk4fwvcrqqQMDZ7Q982tT+B7sU8xV4jYBtFLseQ= =iEFE -----END PGP SIGNATURE-----

1 1

[OSSA-2020-004] Keystone: Keystone credential endpoints allow owner modification and are not protected from a scoped context (CVE PENDING)
by Gage Hugo 08 May '20

08 May '20

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ================================================================================================================= OSSA-2020-004: Keystone credential endpoints allow owner modification and are not protected from a scoped context ================================================================================================================= :Date: May 06, 2020 :CVE: Pending Affects ~~~~~~~ - - Keystone: <15.0.1, ==16.0.0 Description ~~~~~~~~~~~ kay reported two vulnerabilities in keystone's EC2 credentials API. Any authenticated user could create an EC2 credential for themselves for a project that they have a specified role on, then perform an update to the credential user and project, allowing them to masquerade as another user. (CVE #1 PENDING) Any authenticated user within a limited scope (trust/oauth/application credential) can create an EC2 credential with an escalated permission, such as obtaining admin while the user is on a limited viewer role. (CVE #2 PENDING) Both of these vulnerabilities potentially allow a malicious user to act as admin on a project that another user has the admin role on, which can effectively grant the malicious user global admin privileges. Patches ~~~~~~~ - - https://review.opendev.org/725895 (Rocky) - - https://review.opendev.org/725893 (Stein) - - https://review.opendev.org/725891 (Train) - - https://review.opendev.org/725888 (Ussuri) - - https://review.opendev.org/725886 (Victoria) Credits ~~~~~~~ - - kay (CVE Pending) References ~~~~~~~~~~ - - https://launchpad.net/bugs/1872733 - - https://launchpad.net/bugs/1872735 - - http://cve.mitre.org/cgi-bin/cvename.cgi?name=Pending Notes ~~~~~ - - The stable/rocky branch is under extended maintenance and will receive no new point releases, but a patch for it is provided as a courtesy. -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEWa125cLHIuv6ekof56j9K3b+vREFAl6zE70ACgkQ56j9K3b+ vREQsBAAnHZLyrbjSwu7/CEdDVfb0sQZfDvyuXMttzouXQ6ZwEgLFKzc/aFWMjru loyst9jAx2pJzvxDfMYO11oU0M5tYFCFxhKsVvu+3ggbcNHeov1s25bPkxE7A2j7 IYJj9b+bbieYVj1ru3FJjDl3iTae4K73DeHNBCdxTSeahJZdya7hiboA1VJFt4p7 fNqU3+szsYt/vwspPBi7x+xnZszIMaUw8tVgxzB4KVD6YXbDR9Mp7itH77kGdn8l e3OpnURvfaIkPbK6fqE6jjwjQEL/6+Ahffaf4KqvsdjbAcdQRpK0UQrBX+n6DIWd TRwV/W7bEy64HrC16W78fcBlegRmEUUM4xNmdll3lwUS5KqfEeM3vXU4Ksfe9tQ2 8fDU1hDALcC55+2CMMrdFfmX/MBSTz0HVmP4snaGuoXBL/iQz22OmekFKC1tmXxb +vAtOUBsdzphRZn9KWvPIHOFGeuepWb9W0eN594JT2pdHfniLj6EaPrBaN63l7M/ pu0DTPygN5IdUXv6v/vquQZp50CaN59okmXDNiFkBeHsfaAqhdyjJjRaYvyU62OA apjVam8/f2HM0RC0vvpIqv0z0kU55NPCo61dlMZPg6U9JiQd2PzBqvEtDF1lyByF vz5e+r9fmtRcgCJIYr0Z7VlOlSMONpITN03oICaexieDTEXDXHc= =lSDG -----END PGP SIGNATURE-----

1 1