- OpenStack-announce - lists.openstack.org

[OSSN-0089] Missing configuration option in Secure Live Migration guide leads to unencrypted traffic
by Josephine Seifert 13 Apr '21

13 Apr '21

Missing configuration option in Secure Live Migration guide leads to unencrypted traffic -------------------------------------------------------------------------------------------------------------------- ### Summary ### The guide to enable secure live migration with QEMU-native tls on nova compute nodes missed an important config option. Without this option a hard-coded part in nova is triggerd which sets the default route to TCP instead of TLS. This leads to an unecrypted migration of the ram without throwing any kind of Error. ### Affected Services / Software ### Nova / Victoria, Ussuri, Train, Stein (might also be affected: Rocky, Queens, Pike, Ocata) ### Discussion ### In the OpenStack guide to setup secure live migration with QEMU-native tls there are a few configuration options given, which have to be applied to nova compute nodes. After following the instructions and setting up everything it seems to work as expected. But after checking that libvirt is able to use tls using tcpdump to listen on the port for tls while manually executing libvirt commands, the same check for live migration of an instance through openstack fails. Listening on the port for unencrypted tcp-traffic shows that OpenStack still uses the unencrypted TCP path instead of the TLS one for the migration. The reason for this is a patch from Ocata which adds the calculation of the live-migration-uri in code: https://review.opendev.org/c/openstack/nova/+/410817/ The config parameter ``live_migration_uri`` was deprecated in favor of ``live_migration_scheme`` and the default set to tcp. This leads to the problem that if none of these two config options are set, libvirt will always use the default tcp connection. To enable QEMU-native TLS to be used in nova one of them has to be set so that a TLS connection can be established. Currently the guide does not show that this is necessary and there was no other documentation indicating that these config options are important for the usage of QEMU-native TLS. As there is no documentation which recognizes this and it is hard to find this problem as the migration happens even without those config option set - not stating that it is still unencrypted, it might have been unrecognized in various deployments, which followed the guide. ### Recommended Actions ### For deployments using secure live migration with QEMU-native TLS: 1. Check the config of all nova compute nodes. The ``libvirt`` section needs to have either ``live_migration_uri`` (deprecated) or ``live_migration_scheme`` configured. 2. If neither of those config options are present, add ``live_migration_scheme = tls`` to enable the use of the tls connection. #### Patches #### The guide for secure live migration was updated to reflect the necessary configuration options and now has a note, which warns users that not setting all config options may lead into a seemingly working deployment, which still uses unencrypted traffic for the ram-migration. Master(Wallaby): https://review.opendev.org/c/openstack/nova/+/781030 Victoria: https://review.opendev.org/c/openstack/nova/+/781211 Ussuri: https://review.opendev.org/c/openstack/nova/+/782126 Train: https://review.opendev.org/c/openstack/nova/+/782430 Stein: https://review.opendev.org/c/openstack/nova/+/783199 ### Contacts / References ### Author: Josephine Seifert, secustack GmbH This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0089 Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/1919357 Mailing List : [Security] tag on openstack-discuss(a)lists.openstack.org OpenStack Security Project : https://launchpad.net/~openstack-ossg

1 0

[OSSN-0088] Some of the Glance metadef APIs likely to leak resources
by Abhishek Kekane 09 Mar '21

09 Mar '21

Some of the Glance metadef APIs likely to leak resources ------------------------------------------------------------------------------- ### Summary ### Metadef APIs are vulnerable and potentially leaking information to unauthorized users and also there is currently no limit on creation of metadef namespaces, objects, properties, resources and tags. This can be abused by malicious users to fill the Glance database resulting in a Denial of Service (DoS) condition. ### Affected Services / Software ### Glance ### Discussion ### There is no restriction on creation of metadef namespaces, objects, properties, resources and tags as well as it could also leak the information to unauthorized users or to the users outside of the project. By taking advantage of this lack of restrictions around metadef APIs, a a single user could fill the Glance database by creating unlimited resources, resulting in a Denial Of Service (DoS) style attack. Glance does allow metadef APIs to be controlled by policy. However, the default policy setting for metadef APIs allows all users to create or read the metadef information. Because metadef resources are not properly isolated to the owner, any use of them with potentially sensitive names (such as internal infrastructure details, customer names, etc) could unintentionally expose that information to a malicious user. ### Recommended Actions ### Since these fundamental issues have been present since the API was introduced, the Glance project is recommending operators disable all metadef APIs by default in their deployments. Here is an example of disabling the metadef APIs in the deployments for current stable OpenStack releases either in policy.json or policy.yaml. ---- begin example policy.json/policy.yaml snippet ---- "metadef_default": "!", "get_metadef_namespace": "rule:metadef_default", "get_metadef_namespaces": "rule:metadef_default", "modify_metadef_namespace": "rule:metadef_default", "add_metadef_namespace": "rule:metadef_default", "get_metadef_object": "rule:metadef_default", "get_metadef_objects": "rule:metadef_default", "modify_metadef_object": "rule:metadef_default", "add_metadef_object": "rule:metadef_default", "list_metadef_resource_types": "rule:metadef_default", "get_metadef_resource_type": "rule:metadef_default", "add_metadef_resource_type_association": "rule:metadef_default", "get_metadef_property": "rule:metadef_default", "get_metadef_properties": "rule:metadef_default", "modify_metadef_property": "rule:metadef_default", "add_metadef_property": "rule:metadef_default", "get_metadef_tag": "rule:metadef_default", "get_metadef_tags": "rule:metadef_default", "modify_metadef_tag": "rule:metadef_default", "add_metadef_tag": "rule:metadef_default", "add_metadef_tags": "rule:metadef_default" ---- end example policy.json/policy.yaml snippet ---- To re-enable metadef policies to be allowed to be admin only, operator(s) can make a change in respective policy.json or policy.yaml as shown below; (assuming all metadef policies are configured to use rule:metadeta_default as shown in above example) ---- begin example policy.json/policy.yaml snippet ---- "metadef_default": "rule:admin", ---- begin example policy.json/policy.yaml snippet ---- Operators with users that depend on metadef APIs may choose to leave these accessible to all users. In that case, education of users about the potential for information leakage in the resource names is advisable so that vulnerable practices can be altered as mitigation. To re-enable metadef policies to all users, operator(s) can make a change in respective policy.json or policy.yaml as shown below; (assuming all metadef policies are configured to use rule:metadeta_default as shown in above example) ---- begin example policy.json/policy.yaml snippet ---- "metadef_default": "", ---- begin example policy.json/policy.yaml snippet ---- ### Contacts / References ### Author: Abhishek Kekane, Red Hat Author: Lance Bragstad, Red Hat This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0088 Original LaunchPad Bug : https://bugs.launchpad.net/glance/+bug/1545702 Original LaunchPad Bug : https://bugs.launchpad.net/glance/+bug/1916926 Original LaunchPad Bug : https://bugs.launchpad.net/glance/+bug/1916922 Mailing List : [Security] openstack-security(a)lists.openstack.org OpenStack Security Project : https://launchpad.net/~openstack-ossg Thanks & Best Regards, Abhishek Kekane

1 0

[OSSN-0087] Ceph user credential leakage to consumers of OpenStack Manila
by gouthampravi＠gmail.com 16 Dec '20

16 Dec '20

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Ceph user credential leakage to consumers of OpenStack Manila - ------------------------------------------------------------- ### Summary ### OpenStack Manila users can request access on a share to any arbitrary cephx user, including privileged pre-existing users of a Ceph cluster. They can then retrieve access secret keys for these pre-existing ceph users via Manila APIs. A cephx client user name and access secret key are required to mount a Native CephFS manila share. With a secret key, a manila user can impersonate a pre-existing ceph user and gain capabilities to manipulate resources that the manila user was never intended to have access to. It is possible to even obtain the default ceph "admin" user's key in this manner, and execute any commands as the ceph administrator. ### Affected Services / Software ### - - OpenStack Shared File Systems Service (Manila) versions Mitaka (2.0.0) through Victoria (11.0.0) - - Ceph Luminous (<=v12.2.13), Mimic (<=v13.2.10), Nautilus (<=v14.2.15), Octopus (<=v15.2.7) ### Discussion ### OpenStack Manila can provide users with Native CephFS shared file systems. When a user creates a "share" (short for "shared file system") via Manila, a CephFS "subvolume" is created on the Ceph cluster and exported. After creating their share, a user can specify who can have access to the share with the help of "cephx" client user names. A cephx client corresponds to Ceph Client Users [2]. When access is provided, a client user "access key" is returned via manila. A ceph client user account is required to access any ceph resource. This includes interacting with Ceph cluster infrastructure daemons (ceph-mgr, ceph-mds, ceph-mon, ceph-osd) or consuming Ceph storage via RBD, RGW or CephFS. Deployment and orchestration services like ceph-ansible, nfs-ganesha, kolla, tripleo need ceph client users to work, as do OpenStack services such as cinder, manila, glance and nova for their own interactions with Ceph. For the purpose of illustrating this vulnerability, we'll call them "pre-existing" users of the Ceph cluster. Another example of a pre-existing user includes the "admin" user that is created by default on the ceph cluster. In theory, manila's cephx users are no different from a ceph client user. When a manila user requests access to a share, a corresponding ceph user account is created if one already does not exist. If a ceph user account already exists, the existing capabilities of that user are adjusted to provide them permissions to access the manila share in question. There is no reasonable way for this mechanism to know what pre-existing ceph client users must be protected against unauthorized abuse. Therefore there is a risk that a manila user can claim to be a pre-existing ceph user to steal their access secret key. To resolve this issue, the ceph interface that manila uses was patched to no longer allow manila to claim a pre-existing user account that didn't create. By consequence this means that manila users cannot use cephx usernames that correspond to ceph client users that exist outside of manila. ### Recommended Actions ### #. Upgrade your ceph software to the latest patched releases of ceph to take advantage of the fix to this vulnerability. #. Audit cephx access keys provisioned via manila. You may use "ceph auth ls" and ensure that no clients have been compromised. If they have been, you may need to delete and recreate the client credentials to prevent unauthorized access. #. The audit can also be performed on manila by enumerating all CephFS shares and their access rules as a system administrator. If a reserved ceph client username has been used, you may deny access and recreate the client credential on ceph to refresh the access secret. No code changes were necessary in the OpenStack Shared File System service (manila). With an upgraded ceph, when manila users attempt to provide share access to a cephx username that they cannot use, the access rule's "state" attribute is set to "error" because this operation is no longer permitted. ### Patches ### The Ceph community has provided the following patches: Ceph Octopus: https://github.com/ceph/ceph/commit/1b8a634fdcd94dfb3ba650793fb1b6d09af65e05 Ceph Nautilus: https://github.com/ceph/ceph/commit/7e3e4e73783a98bb07ab399438eb3aab41a6fc8b Ceph Luminous: https://github.com/ceph/ceph/commit/956ceb853a58f6b6847b31fac34f2f0228a70579 The fixes are in the latest releases of Ceph Nautilus (14.2.16) and Ceph Octopus (15.2.8). The patch for Luminous was provided as a courtesy to possible users of OpenStack Manila, however the Ceph community no longer produces releases for Luminous or Mimic as they are end of life. See `here for information about ceph releases. <https://docs.ceph.com/en/latest/releases/general/>`_ ### Contacts / References ### Author: - - Pacha Ravi, Goutham gouthamr(a)redhat.com (Red Hat) Credits: - - Garbutt, John john(a)johngarbutt.com (StackHPC) - - Babel, Jahson jahson.babel(a)cc.in2p3.fr (Centre de Calcul de l'IN2P3) This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0087 Original LaunchPad Bug : https://launchpad.net/bugs/1904015 Mailing List : [Security] tag on openstack-discuss(a)lists.openstack.org OpenStack Security Project : https://launchpad.net/~openstack-ossg CVE: CVE-2020-27781 -----BEGIN PGP SIGNATURE----- wsFcBAEBCAAGBQJf2raCAAoJENJP32eYWZR3mREP/ij+So0KHK7dD3WAdcVK 0JdGzwOjX2Bc4/7g5RPzn4RaxZKicsBOWqESCTTBl94oG4XvTax3fW0E6VlL L6XoV+At1cEvptONDoZ0faCSHfTng1J73rHMo9v+cmxmOuEwXReghArS86tS KIeRWviW9hyNmZfhJxuAC9ICR0HglhT5VHqNtAjL5WzoFGMtC4VeJ7e8rf8r PLjvYGOPzNDj8wAn5UvTnJgkT1tbbIZQai4o+QlDJK5eEuEQnwGTUQ/umx/a z2DeuCnDDxJeOFcWEgkDzTQsE6e7dO4FvoIIsZ3u5pA0Rhw31QfpupUsLAYH WhAjt7cImKRTfza/zVuS7PAko2fMmuNHyHEQQh2Y80S4nkdo/WAfUaBft8eO vdNlvunBQA2E7mlK6oxNF22k/pX49N47vVqGttPFA1kNPFg2qLcc8mJIxpjf V4sJVfMO/DuQaU1zTH/P9KsYm/hlyVzLELEvDR43jmWg4p4btZT8Z2OVD80r 9/dRMcbRQl3yq1C2L7yyKVOc6Pw9HJ90ixXpgv7ZT6TbwAPzFe/euITmA6H0 EGzinRg7JmfFFnf/9FBEZJRL46/idMLVNRo2XioA6+o2kngkwSsD+uJTlMFG XQJINZwrbL1xpuh3VGaOI44yCimsQwNGURH2NmZ7uFBKy6CHYXX42ydnQk51 w9qp =o0Lx -----END PGP SIGNATURE-----

1 0

[OSSA-2020-008] horizon: Open redirect in workflow forms (CVE-2020-29565)
by Gage Hugo 07 Dec '20

07 Dec '20

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================== OSSA-2020-008: Open redirect in workflow forms ============================================== :Date: December 03, 2020 :CVE: CVE-2020-29565 Affects ~~~~~~~ - - Horizon: <15.3.2, >=16.0.0 <16.2.1, >=17.0.0 <18.3.3, >=18.4.0 <18.6.0 Description ~~~~~~~~~~~ Pritam Singh (Red Hat) reported a vulnerability in Horizon's workflow forms. Previously there was a lack of validation on the "next" parameter, which would allow someone to supply a malicious URL in Horizon that can cause an automatic redirect to the provided malicious URL. Patches ~~~~~~~ - - https://review.opendev.org/758843 (Stein) - - https://review.opendev.org/758841 (Train) Credits ~~~~~~~ - - Pritam Singh from Red Hat (CVE-2020-29565) References ~~~~~~~~~~ - - https://launchpad.net/bugs/1865026 - - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-29565 -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEWa125cLHIuv6ekof56j9K3b+vREFAl/OrjwACgkQ56j9K3b+ vRG/Gg//Tyj5La8eFwIrwhpDbV/tKNFS+t3NzuhJzLS24WNS9cLf5yDronRdBPdT Ow2OegTZ7K5GyoRARpycTjtE66RIizX9I8Kx27FXPc83hLYYOs/MButYpqcp0swM 687RXZGFcZ5HZtPuRuTcclEcyhzvcUX7HXmznOCmVOHchr+RXzmp6cXC7tyCuNkV cGuuMtptDfkFmn2MpGmiTWEiMusMRbV5HqeyY39jg5dwph0kbMCcuzkX6c2WHubE T+rjVKbmqHr+v7og6mkZoK+pVk6Ulta/lGsYh/0NlszdQw3poN4FIt//TIwJZVwx WSlbMt6IwBW5XiPXvjpX9Awis6CT0jxlIV5XBq+klr3Jo+YnDsChElIPQs3CRKoM vqXVextHCk3LK1Evs3FkBns2Taro4tWOlkGYKR6INT4F1TJKNIzIUiF08673uF3B 8zXDfnVEb7tEMqwu6OdVnfQQ4SRu7uyrN1sHhtwIyfK10AAI7gfJL/wbItJy21Om SQahTfDnikEY5gYYU+NH0LBMXkE0I/T+uvPh4LgP7wUxCMR9uI8+iA0711Gp/aPD WUdm3pUfIJYE7Gq6sT7BJQftHyMPcxOBj+MIrmFDFOxyPV70Mub+f34zxdu3Qoda tZNpy/BGL19VqrlRa9R8H65tzzNy7k5GqkaUYEF5/LegfUgZOTo= =jr+k -----END PGP SIGNATURE-----

1 0

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

16 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 13 Oct '20

13 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 13 Oct '20

13 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 25 Aug '20

25 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 18 Jun '20

18 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