May 2020 - openstack-discuss - lists.openstack.org

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

07 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

[OSSA-2020-003] Keystone: Keystone does not check signature TTL of the EC2 credential auth method (CVE PENDING)
by Gage Hugo 07 May '20

07 May '20

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ====================================================================================== OSSA-2020-003: Keystone does not check signature TTL of the EC2 credential auth method ====================================================================================== :Date: May 06, 2020 :CVE: Pending Affects ~~~~~~~ - - Keystone: <15.0.1, ==16.0.0 Description ~~~~~~~~~~~ kay reported a vulnerability with keystone's EC2 API. Keystone doesn't have a signature TTL check for AWS signature V4 and an attacker can sniff the auth header, then use it to reissue an openstack token an unlimited number of times. Patches ~~~~~~~ - - https://review.opendev.org/725385 (Rocky) - - https://review.opendev.org/725069 (Stein) - - https://review.opendev.org/724954 (Train) - - https://review.opendev.org/724746 (Ussuri) - - https://review.opendev.org/724124 (Victoria) Credits ~~~~~~~ - - kay (CVE Pending) References ~~~~~~~~~~ - - https://launchpad.net/bugs/1872737 - - 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+vREFAl6zEjwACgkQ56j9K3b+ vRFejhAAvzq3MBwKGXIKsJxQmwVS0RxVFifTAfnKIjBGskG3knWkQHopY0IcmwoZ 3Kv2AnRgFVBuQpZ0t9Y3S3U7KRI63FT+kzA3gy9sB+h7rdqzquxejXvljRMGJlex WRCOQwRP4prFpzpUqzBg9/bIAyWpkrjJIvz7iJ9U3z6MbrZIjV+YEZ3JIRQTdMUj MajgwJ4EDynkh8trm63n7Gyuvq8ukj1FCrG1APWJi96HhwNz6XwiqXIWci4CTaEW sY9v8luETMCyv+nY2pt9IF8wXOaJKJXPTilf6sisjN2zDq+UWgsxEC0sp3h09tnZ m6cy3OvUQeDmdJVQ/VNsfUTeRYRvYri2u44FaOUBjsNxeZca1U4MCVkAiN9BBzkg k1Xb8zgGoXaytT/lzzyr67h6ZghKm6cnSUktWnX56847byOMPi/g9q1cu0edUwwC 7SDaQ08JbsEstiXtPVBhatTLxbjlNy5eql6NaZmFQatYJAQKZsasvwV4YBv290mu OsVHUEqjmYk4b4CZNPQC2681CDtAQpiLuasYiLnxC6I+zBTwfP+6tzP0xVHW4woi 4Jhl/watZMudrtMS3YoOmwZ4iFNJRzQcDWmiAr0CZiC0NGamLjvHWHRslnvmhy92 kSGWLilaMD5vBODXVY82lQHrbl96dPRbpe8/z29sALsEs6aNFYk= =qyBV -----END PGP SIGNATURE-----

1 1

[Syntribos] Does anyone still use this?
by Gage Hugo 07 May '20

07 May '20

The Security SIG has recently been looking into updating several sites/documentation and one part we discussed the last couple meetings was the security tools listings[0]. One of the projects listed there, Syntribos, doesn't appear to have much activity[1] outside of zuul/python/docs maintenance and the idea of retiring the project was mentioned. However, there does seem to be an occasional bug-fix submitted, so we are sending this email out to see if anyone is still utilizing Syntribos. If so, please either respond here, reach out to us in the #openstack-security irc channel, or fill out the section in the Security SIG Agenda etherpad[2]. Thanks! [0] https://security.openstack.org/#security-tool-development [1] https://review.opendev.org/#/q/project:openstack/syntribos [2] https://etherpad.openstack.org/p/security-agenda

2 2

[infra][qa][sigs][tc] Forming a Testing and Collaboration Tools (TaCT) SIG
by Jeremy Stanley 07 May '20

07 May '20

The Infrastructure team, and the CI team before it, has traditionally existed to care for the continuous integration and collaboration infrastructure on which the OpenStack community relies. With the rise of the OpenDev Collaboratory as a distinct effort outside of (but still primarily in service of) OpenStack, the majority of the team's former systems administration activities are no longer occurring under the authority of OpenStack. Most of the software and configuration management repositories previously in the care of the Infra team are also no longer official OpenStack deliverables, and have become part of OpenDev as well (and their biggest development effort, Zuul+Nodepool, was already spun out as an independent Open Infrastructure Project last year). With the above responsibilities moved elsewhere, the existence of a formal team is less of a necessity. What remains is a need to support OpenStack's project-specific testing and collaboration tooling and services, primarily job configuration and other things which shouldn't currently be generalized into components of the OpenDev Collaboratory. To this end, I propose the creation of a new Testing and Collaboration Tools (TaCT) SIG which would serve the role currently occupied by the OpenStack Infrastructure team. I'm open to alternative names, but employing the vague term "infrastructure" has perpetually confused newcomers to our community, so this seems like an opportunity for something less overloaded. The TaCT SIG would consist of the usual suspects: people who review OpenStack job configuration changes, people who dig into problems with test frameworks to unblock the integrated gate queue, people who figure out strange Python packaging related issues, people who help work out lapsed control of Launchpad admin groups... also, ideally, the person selected by the TC to serve as OpenStack's representative on the OpenDev Advisory Council would be heavily involved. Many of these activities are closely related to work the Quality Assurance team is doing, so hopefully folks who are active in QA will also participate in this SIG. What do you think? Does this satisfactorily capture the infrastructure needs of the OpenStack community, and could it serve as an alternative to the current Infrastructure team? -- Jeremy Stanley

5 7

OpenDev Events Update - we need your feedback!
by Ashlee Ferguson 07 May '20

07 May '20

Hi everyone, Thanks so much for your feedback that’s continually helping us shape these virtual OpenDev events[1]. Keep reading this email for some important updates on all three events! 1. OpenDev: Large-scale Usage of Open Infrastructure Software - June 29 - July 1 (1300 - 1600 UTC each day) - Registration is open[2]! - High-level schedule coming soon; Find a brief topic summary and more information here[1] 2. OpenDev: Hardware Automation - July 20 - 22 - Help us pick a time - visit this etherpad[3] and +1 the times you’re available and the topics you would like to cover - please provide your input by this Thursday, March 7. 3. OpenDev: Containers in Production - August 10 - 12 - Help us pick a time - visit this etherpad[4] and +1 the times you’re available and the topics you would like to cover - please provide your input by this Thursday, March 7. Find more information and updates on all of these events here[1]. [1] https://www.openstack.org/events/opendev-2020 [2] https://opendev_largescale.eventbrite.com [3] https://etherpad.opendev.org/p/OpenDev_HardwareAutomation [4] https://etherpad.opendev.org/p/OpenDev_ContainersInProduction Thanks! Ashlee Ashlee Ferguson Community & Events Coordinator OpenStack Foundation

1 2

[ironic] II SPUC - The Sanity Preservation Un-Conference
by Iury Gregory 07 May '20

07 May '20

Hello everyone \o/ We are going for the second edition of SPUC! For those who doesn't know what is SPUC check [0]. There is only 3 things you need to do: 1) Fill out the doodle in [1] *, it has options for the next two weeks since May 1st is a holiday. 2) Brainstorm some ideas of things you might want to talk about/present or LEARN! * 3) Dust off your silly hats! * * From Julia's email =) [0] Thank you! [0] http://lists.openstack.org/pipermail/openstack-discuss/2020-March/013521.ht… [1] https://doodle.com/poll/2q5zmv3g6uy2475e -- *Att[]'sIury Gregory Melo Ferreira * *MSc in Computer Science at UFCG* *Software Engineer at Red Hat Czech* *Social*: https://www.linkedin.com/in/iurygregory *E-mail: iurygregory(a)gmail.com <iurygregory(a)gmail.com>*

3 3

[neutron] Agenda of the 08.05.2020 Drivers meeting
by Slawek Kaplonski 07 May '20

07 May '20

Hi, For tomorrows drivers meeting we have 2 new RFEs to be discussed: * https://bugs.launchpad.net/neutron/+bug/1875516 - [RFE] Allow sharing security groups as read-only * https://bugs.launchpad.net/neutron/+bug/1873091/ - [RFE] Neutron ports dns_assignment does not match the designate DNS records for Neutron port See You tomorrow on the meeting. -- Slawek Kaplonski Senior software engineer Red Hat

1 0

[all] [qa] [oslo] Usage of testtools?
by Dmitry Tantsur 07 May '20

07 May '20

Hi folks, Most OpenStack projects use testtools/fixtures/unittest2 for unit tests. It was immensely helpful in Python 2 times, but I wonder if we should migrate away now. I've hit at least these three bugs: https://github.com/testing-cabal/testtools/issues/235 https://github.com/testing-cabal/testtools/issues/275 https://github.com/testing-cabal/testtools/issues/144 We can invest time in fixing them, but I wonder if we should just migrate to the standard unittest (and move oslotest to it) now that we require Python >= 3.6. Thoughts? Dmitry

2 2

[kolla] Kolla klub meeting today
by Mark Goddard 07 May '20

07 May '20

Hi, Just a reminder that we have the third Kolla Klub meeting today at 3pm UTC. We have Gaël Therond and Дмитрий Грачев (Dmitry Grachev) giving case studies. Meeting notes, connection info and agenda: https://docs.google.com/document/d/1EwQs2GXF-EvJZamEx9vQAOSDB5tCjsDCJyHQN5_… Cheers, Mark

1 0

[keystone] How to create a session using trust-scoped token
by Lingxian Kong 06 May '20

06 May '20

Hi keystone team, I met with an issue that can't perform openstack operations using openstack client lib by providing a trust scoped token. However, I can use that token to send HTTP request directly. Here is my code and the error message, http://dpaste.com/1N6AX0R I asked several times in #openstack-keystone IRC channel, but got no response. --- Lingxian Kong Senior Software Engineer Catalyst Cloud www.catalystcloud.nz

2 3