- OpenStack-announce - lists.openstack.org

[OSSA-2021-002] Nova: Open Redirect in noVNC proxy (CVE-2021-3654)
by Jeremy Stanley 27 Sep '21

27 Sep '21

=========================================== OSSA-2021-002: Open Redirect in noVNC proxy =========================================== :Date: July 29, 2021 :CVE: CVE-2021-3654 Affects ~~~~~~~ - Nova: <21.2.3, >=22.0.0 <22.2.3, >=23.0.0 <23.0.3 Description ~~~~~~~~~~~ Swe Aung, Shahaan Ayyub, and Salman Khan with the Monash University Cyber Security team reported a vulnerability affecting Nova's noVNC proxying implementation which exposed access to a well-known redirect behavior in the Python standard library's http.server.SimpleHTTPRequestHandler and thus noVNC's WebSockifyRequestHandler which uses it. By convincing a user to follow a specially-crafted novncproxy URL, the user could be redirected to an unrelated site under control of the attacker in an attempt to convince them to divulge credentials or other sensitive data. All Nova deployments with novncproxy enabled are affected. Errata ~~~~~~ The initial fix did not take into account the possibility of bypass using exactly three slashes. This update provides a more thorough revised fix for the issue. The affected versions list has been updated to indicate versions expected to include the newer solution. Patches ~~~~~~~ - https://review.opendev.org/791807 (Train) - https://review.opendev.org/806629 (errata 1) (Train) - https://review.opendev.org/791806 (Ussuri) - https://review.opendev.org/806628 (errata 1) (Ussuri) - https://review.opendev.org/791805 (Victoria) - https://review.opendev.org/806626 (errata 1) (Victoria) - https://review.opendev.org/791577 (Wallaby) - https://review.opendev.org/805818 (errata 1) (Wallaby) - https://review.opendev.org/791297 (Xena) - https://review.opendev.org/805654 (errata 1) (Xena) Credits ~~~~~~~ - Swe Aung from Monash University Cyber Security team (CVE-2021-3654) - Shahaan Ayyub from Monash University Cyber Security team (CVE-2021-3654) - Salman Khan from Monash University Cyber Security team (CVE-2021-3654) References ~~~~~~~~~~ - https://launchpad.net/bugs/1927677 - https://bugs.python.org/issue32084 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3654 Notes ~~~~~ - The stable/train branch is under extended maintenance and will receive no new point releases, but a patch for it is provided as a courtesy. OSSA History ~~~~~~~~~~~~ - 2021-09-27 - Errata 1 - 2021-07-29 - Original Version -- Jeremy Stanley

1 0

[OSSA-2021-006] Neutron: Routes middleware memory leak for nonexistent controllers (CVE-2021-40797)
by Jeremy Stanley 09 Sep '21

09 Sep '21

======================================================================== OSSA-2021-006: Routes middleware memory leak for nonexistent controllers ======================================================================== :Date: September 09, 2021 :CVE: CVE-2021-40797 Affects ~~~~~~~ - Neutron: <16.4.1, >=17.0.0 <17.2.1, >=18.0.0 <18.1.1 Description ~~~~~~~~~~~ Slawek Kaplonski with Red Hat reported a vulnerability in Neutron's routes middleware. By making API requests involving nonexistent controllers, an authenticated user may cause the API worker to consume increasing amounts of memory, resulting in API performance degradation or denial of service. All Neutron deployments are affected. Patches ~~~~~~~ - https://review.opendev.org/807638 (Queens) - https://review.opendev.org/807637 (Rocky) - https://review.opendev.org/807636 (Stein) - https://review.opendev.org/807635 (Train) - https://review.opendev.org/807634 (Ussuri) - https://review.opendev.org/807633 (Victoria) - https://review.opendev.org/807632 (Wallaby) - https://review.opendev.org/807335 (Xena) Credits ~~~~~~~ - Slawek Kaplonski from Red Hat (CVE-2021-40797) References ~~~~~~~~~~ - https://launchpad.net/bugs/1942179 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-40797 Notes ~~~~~ - The stable/train, stable/stein, stable/rocky, and stable/queens branches are under extended maintenance and will receive no new point releases, but patches for them are provided as a courtesy. -- Jeremy Stanley

1 0

[all][elections][ptl] Project Team Lead Election Conclusion and Results
by Ian Y. Choi 08 Sep '21

08 Sep '21

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: * Barbican : Douglas Mendizábal * Blazar : Pierre Riteau * Cinder : Brian Rosmaita * Cloudkitty : Rafael Weingartner * Cyborg : Bailin Zhang * Designate : Michael Johnson * Ec2 Api : Andrey Pavlov * Freezer : ge cong * Glance : Abhishek Kekane * Horizon : Vishal Manchanda * Ironic : Iury Gregory Melo Ferreira * Kolla : Michal Nasiadka * Kuryr : Maysa de Macedo Souza * Magnum : Feilong Wang * Manila : Goutham Pacha Ravi * Masakari : Radosław Piliszek * Murano : Rong Zhu * Neutron : Lajos Katona * Nova : Sylvain Bauza * Octavia : Gregory Thiemonge * OpenStack Charms : Alex Kavanagh * Openstack Chef : Lance Albertson * OpenStack Helm : Gage Hugo * OpenStackAnsible : Dmitriy Rabotyagov * OpenStackSDK : Artem Goncharov * Quality Assurance : Martin Kopec * Rally : Andrey Kurilin * Release Management : Elod Illes * Requirements : Matthew Thode * Senlin : XueFeng Liu * Solum : Rong Zhu * Storlets : Takashi Kajinami * Swift : Tim Burke * Tacker : Yasufumi Ogawa * Telemetry : Matthias Runge * Tripleo : James Slagle * Trove : Lingxian Kong * Vitrage : Eyal Bar-Ilan * Watcher : chen ke * Winstackers : Lucian Petrut * Zaqar : wang hao Elections: * Cyborg: https://civs1.civs.us/cgi-bin/results.pl?id=E_807146df7d6a1d3b Election process details and results are also available here: https://governance.openstack.org/election/ Thank you to all involved in the PTL election process, Ian Y. Choi, on behalf of the OpenStack Technical Election Officials

1 0

[OSSA-2021-005] Neutron: Arbitrary dnsmasq reconfiguration via extra_dhcp_opts (CVE-2021-40085)
by Jeremy Stanley 31 Aug '21

31 Aug '21

==================================================================== OSSA-2021-005: Arbitrary dnsmasq reconfiguration via extra_dhcp_opts ==================================================================== :Date: August 31, 2021 :CVE: CVE-2021-40085 Affects ~~~~~~~ - Neutron: <16.4.1, >=17.0.0 <17.2.1, >=18.0.0 <18.1.1 Description ~~~~~~~~~~~ Pavel Toporkov reported a vulnerability in Neutron. By supplying a specially crafted extra_dhcp_opts value, an authenticated user may add arbitrary configuration to the dnsmasq process in order to crash the service, change parameters for other tenants sharing the same interface, or otherwise alter that daemon's behavior. This vulnerability may also be used to trigger a configuration parsing buffer overflow in versions of dnsmasq prior to 2.81, which could lead to remote code execution. All Neutron deployments are affected. Patches ~~~~~~~ - https://review.opendev.org/806750 (Ussuri) - https://review.opendev.org/806749 (Victoria) - https://review.opendev.org/806748 (Wallaby) - https://review.opendev.org/806746 (Xena) Credits ~~~~~~~ - Pavel Toporkov (CVE-2021-40085) References ~~~~~~~~~~ - https://launchpad.net/bugs/1939733 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-40085 -- Jeremy Stanley

1 0

[OSSA-2021-004] Neutron: Linuxbridge ARP filter bypass on Netfilter platforms (CVE-2021-38598)
by Jeremy Stanley 17 Aug '21

17 Aug '21

=================================================================== OSSA-2021-004: Linuxbridge ARP filter bypass on Netfilter platforms =================================================================== :Date: August 17, 2021 :CVE: CVE-2021-38598 Affects ~~~~~~~ - Neutron: <16.4.1, >=17.0.0 <17.1.3, ==18.0.0 Description ~~~~~~~~~~~ Jake Yip with ARDC and Justin Mammarella with the University of Melbourne reported a vulnerability in Neutron's linuxbridge driver on newer Netfilter-based platforms (the successor to IPTables). By sending carefully crafted packets, anyone in control of a server instance connected to the virtual switch can impersonate the hardware addresses of other systems on the network, resulting in denial of service or in some cases possibly interception of traffic intended for other destinations. Only deployments using the linuxbridge driver with ebtables-nft are affected. Patches ~~~~~~~ - https://review.opendev.org/804058 (Train) - https://review.opendev.org/804057 (Ussuri) - https://review.opendev.org/804056 (Victoria) - https://review.opendev.org/785917 (Wallaby) - https://review.opendev.org/785177 (Xena) Credits ~~~~~~~ - Jake Yip from ARDC (CVE-2021-38598) - Justin Mammarella from University of Melbourne (CVE-2021-38598) References ~~~~~~~~~~ - https://launchpad.net/bugs/1938670 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-38598 Notes ~~~~~ - The stable/train branch is under extended maintenance and will receive no new point releases, but a patch for it is provided as a courtesy. -- Jeremy Stanley

1 0

[OSSA-2021-003] Keystone: Account name and UUID oracles in account locking (CVE-2021-38155)
by Jeremy Stanley 10 Aug '21

10 Aug '21

=============================================================== OSSA-2021-003: Account name and UUID oracles in account locking =============================================================== :Date: August 10, 2021 :CVE: CVE-2021-38155 Affects ~~~~~~~ - Keystone: >=10.0.0 <16.0.2, >=17.0.0 <17.0.1, >=18.0.0 <18.0.1, >=19.0.0 <19.0.1 Description ~~~~~~~~~~~ Samuel de Medeiros Queiroz with Oi Cloud reported a vulnerability affecting Keystone account locking. By guessing the name of an account and failing to authenticate multiple times, any unauthenticated actor could both confirm the account exists and obtain that account's corresponding UUID, which might be leveraged for other unrelated attacks. All Keystone deployments enabling security_compliance.lockout_failure_attempts are affected. Patches ~~~~~~~ - https://review.opendev.org/790444 (Train) - https://review.opendev.org/790443 (Ussuri) - https://review.opendev.org/790442 (Victoria) - https://review.opendev.org/790440 (Wallaby) - https://review.opendev.org/759940 (Xena) Credits ~~~~~~~ - Samuel de Medeiros Queiroz from Oi Cloud (CVE-2021-38155) References ~~~~~~~~~~ - https://launchpad.net/bugs/1688137 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-38155 -- Jeremy Stanley

1 0

[OSSA-2021-002] Nova: Open Redirect in noVNC proxy (CVE-2021-3654)
by Jeremy Stanley 29 Jul '21

29 Jul '21

=========================================== OSSA-2021-002: Open Redirect in noVNC proxy =========================================== :Date: July 29, 2021 :CVE: CVE-2021-3654 Affects ~~~~~~~ - Nova: <21.2.3, >=22.0.0 <22.2.3, >=23.0.0 <23.0.2 Description ~~~~~~~~~~~ Swe Aung, Shahaan Ayyub, and Salman Khan with the Monash University Cyber Security team reported a vulnerability affecting Nova's noVNC proxying implementation which exposed access to a well-known redirect behavior in the Python standard library's http.server.SimpleHTTPRequestHandler and thus noVNC's WebSockifyRequestHandler which uses it. By convincing a user to follow a specially-crafted novncproxy URL, the user could be redirected to an unrelated site under control of the attacker in an attempt to convince them to divulge credentials or other sensitive data. All Nova deployments with novncproxy enabled are affected. Patches ~~~~~~~ - https://review.opendev.org/791807 (Train) - https://review.opendev.org/791806 (Ussuri) - https://review.opendev.org/791805 (Victoria) - https://review.opendev.org/791577 (Wallaby) - https://review.opendev.org/791297 (Xena) Credits ~~~~~~~ - Swe Aung from Monash University Cyber Security team (CVE-2021-3654) - Shahaan Ayyub from Monash University Cyber Security team (CVE-2021-3654) - Salman Khan from Monash University Cyber Security team (CVE-2021-3654) References ~~~~~~~~~~ - https://launchpad.net/bugs/1927677 - https://bugs.python.org/issue32084 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3654 Notes ~~~~~ - The stable/train branch is under extended maintenance and will receive no new point releases, but a patch for it is provided as a courtesy. -- Jeremy Stanley

1 0

[OSSA-2021-001] Neutron: Anti-spoofing bypass for Open vSwitch networks (CVE-2021-20267)
by Jeremy Stanley 12 Jul '21

12 Jul '21

============================================================= OSSA-2021-001: Anti-spoofing bypass for Open vSwitch networks ============================================================= :Date: July 12, 2021 :CVE: CVE-2021-20267 Affects ~~~~~~~ - Neutron: <16.3.3, >=17.0.0 <17.1.3, =18.0.0 Description ~~~~~~~~~~~ David Sinquin with Gandi.net reported a vulnerability in Neutron's default Open vSwitch firewall rules. By sending carefully crafted packets, anyone in control of a server instance connected to the virtual switch can impersonate the IPv6 addresses of other systems on the network, resulting in denial of service or in some cases possibly interception of traffic intended for other destinations. Only deployments using the Open vSwitch driver are affected. Patches ~~~~~~~ - https://review.opendev.org/777873 (Queens) - https://review.opendev.org/791470 (Queens) - https://review.opendev.org/777786 (Rocky) - https://review.opendev.org/791469 (Rocky) - https://review.opendev.org/777872 (Stein) - https://review.opendev.org/791500 (Stein) - https://review.opendev.org/777785 (Train) - https://review.opendev.org/791468 (Train) - https://review.opendev.org/777784 (Ussuri) - https://review.opendev.org/791467 (Ussuri) - https://review.opendev.org/777783 (Victoria) - https://review.opendev.org/791465 (Victoria) - https://review.opendev.org/776599 (Wallaby) - https://review.opendev.org/791464 (Wallaby) - https://review.opendev.org/783743 (Xena) Credits ~~~~~~~ - David Sinquin from Gandi.net (CVE-2021-20267) References ~~~~~~~~~~ - https://launchpad.net/bugs/1902917 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-20267 Notes ~~~~~ - The stable/train, stable/stein, stable/rocky, and stable/queens branches are under extended maintenance and will receive no new point releases, but patches for them are provided as a courtesy. -- Jeremy Stanley

1 0

OpenStack Wallaby is officially released!
by Herve Beraud 14 Apr '21

14 Apr '21

Hello OpenStack community, I'm excited to announce the final releases for the components of OpenStack Wallaby, which concludes the Wallaby 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/wallaby/ Congratulations to all of the teams who have contributed to this release! Our next production cycle, Xena, has already started. We will virtually meet April 19-23, 2021, for the Xena Project Teams Gathering. More details can be found on the PTG site: https://www.openstack.org/ptg Thanks, Hervé Beraud and the Release Management team -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

1 0

[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