[oslo][security-sig] Please revisit your open vulnerability report
Please help the OpenStack Vulnerability Management Team by taking a look at the following report:
keystonemiddleware connections to memcached from neutron-server grow beyond configured values https://launchpad.net/bugs/1883659
Can it be exploited by a nefarious actor, and if so, how? Is it likely to be fixable in all our supported stable branches, respecting stable backport policy? What deployment configurations and options might determine whether a particular installation is susceptible? This is the sort of feedback we depend on to make determinations regarding whether and how to keep the public notified, so they can make informed decisions.
Thanks for doing your part to keep our users safe!
On 2/18/21 8:49 AM, Jeremy Stanley wrote:
Please help the OpenStack Vulnerability Management Team by taking a look at the following report:
keystonemiddleware connections to memcached from neutron-server grow beyond configured values https://launchpad.net/bugs/1883659Can it be exploited by a nefarious actor, and if so, how? Is it likely to be fixable in all our supported stable branches, respecting stable backport policy? What deployment configurations and options might determine whether a particular installation is susceptible? This is the sort of feedback we depend on to make determinations regarding whether and how to keep the public notified, so they can make informed decisions.
Thanks for doing your part to keep our users safe!
I ended up just closing this one for Oslo because it appears that using the oslo.cache backend actually fixes the bug.
I also pushed a patch for a formerly private bug[0] that just bumps our minimum pyyaml version to avoid a vulnerability. I suspect everyone is already running newer versions of it, but if not now they know that they should. :-)
Strangely, I don't remember getting an email notification about that bug. I thought coresec team members were notified about private security bugs. I guess I'll have to keep a closer eye on our bug list from now on.
On 2021-02-18 10:36:52 -0600 (-0600), Ben Nemec wrote: [...]
I ended up just closing this one for Oslo because it appears that using the oslo.cache backend actually fixes the bug.
Thanks!
I also pushed a patch for a formerly private bug[0] that just bumps our minimum pyyaml version to avoid a vulnerability. I suspect everyone is already running newer versions of it, but if not now they know that they should. :-)
Strangely, I don't remember getting an email notification about that bug. I thought coresec team members were notified about private security bugs. I guess I'll have to keep a closer eye on our bug list from now on.
Please double-check https://launchpad.net/oslo.config/+sharing and make sure "Private Security: All" is shared with "OpenStack Vulnerability Management team (openstack-vuln-mgmt)" but it's also just possible we missed triaging that report when it was opened. VMT members do periodically check https://launchpad.net/openstack/+bugs?field.information_type%3Alist=PRIVATES... for anything that's slipped through the cracks. Not often, but I'm pretty sure it's not been as long as the ~1.5 years since that bug was opened.
On 2/18/21 11:03 AM, Jeremy Stanley wrote:
On 2021-02-18 10:36:52 -0600 (-0600), Ben Nemec wrote: [...]
I ended up just closing this one for Oslo because it appears that using the oslo.cache backend actually fixes the bug.
Thanks!
I also pushed a patch for a formerly private bug[0] that just bumps our minimum pyyaml version to avoid a vulnerability. I suspect everyone is already running newer versions of it, but if not now they know that they should. :-)
Strangely, I don't remember getting an email notification about that bug. I thought coresec team members were notified about private security bugs. I guess I'll have to keep a closer eye on our bug list from now on.
Please double-check https://launchpad.net/oslo.config/+sharing and make sure "Private Security: All" is shared with "OpenStack Vulnerability Management team (openstack-vuln-mgmt)" but it's also just possible we missed triaging that report when it was opened. VMT members do periodically check https://launchpad.net/openstack/+bugs?field.information_type%3Alist=PRIVATES... for anything that's slipped through the cracks. Not often, but I'm pretty sure it's not been as long as the ~1.5 years since that bug was opened.
Okay, I did that. I think we may need to audit all of the Oslo projects because the spot check I did on oslo.policy also did not have the needed sharing, and did have someone who doesn't even work on OpenStack anymore with access to private security bugs(!). I don't appear to have permission to change that either. :-/
The other issue is probably that the Oslo projects are not part of the openstack org on launchpad. We did that because of the number of projects made it easier to keep track of them if they were their own org, but it does mean they wouldn't show up under a query for the openstack org, unfortunately.
I thought I remembered getting a notification from launchpad itself when a private security bug was opened, but it's been long enough since that last would have happened that I may be wrong.
On 2021-02-18 12:39:52 -0600 (-0600), Ben Nemec wrote: [...]
Okay, I did that. I think we may need to audit all of the Oslo projects because the spot check I did on oslo.policy also did not have the needed sharing, and did have someone who doesn't even work on OpenStack anymore with access to private security bugs(!). I don't appear to have permission to change that either. :-/
Aha, thanks, that explains why the VMT members wouldn't have been notified (or even able to see the bug at all).
If you put together a list of which ones need fixing, I think I have a backdoor via being a member of the group which is the owner of the groups which are listed as maintainer or owner of many of those projects, so should be able to temporarily add myself to a group which has access to adjust the sharing on them. Also at the moment, the only Oslo deliverables which are listed as having explicit VMT oversight are castellan and oslo.config. If there are others you want our proactive help with, please add this tag to them:
https://governance.openstack.org/tc/reference/tags/vulnerability_managed.htm...
The other issue is probably that the Oslo projects are not part of the openstack org on launchpad. We did that because of the number of projects made it easier to keep track of them if they were their own org, but it does mean they wouldn't show up under a query for the openstack org, unfortunately.
[...]
And also means that our periodic reviews of Private Security bugs for projects which are "part of OpenStack" on LP wouldn't have seen it even if we'd had permission.
Finally got back to this. More below.
On 2/18/21 1:13 PM, Jeremy Stanley wrote:
On 2021-02-18 12:39:52 -0600 (-0600), Ben Nemec wrote: [...]
Okay, I did that. I think we may need to audit all of the Oslo projects because the spot check I did on oslo.policy also did not have the needed sharing, and did have someone who doesn't even work on OpenStack anymore with access to private security bugs(!). I don't appear to have permission to change that either. :-/
Aha, thanks, that explains why the VMT members wouldn't have been notified (or even able to see the bug at all).
If you put together a list of which ones need fixing, I think I have a backdoor via being a member of the group which is the owner of the groups which are listed as maintainer or owner of many of those projects, so should be able to temporarily add myself to a group which has access to adjust the sharing on them. Also at the moment, the only Oslo deliverables which are listed as having explicit VMT oversight are castellan and oslo.config. If there are others you want our proactive help with, please add this tag to them:
https://governance.openstack.org/tc/reference/tags/vulnerability_managed.htm...
I'll bring up VMT again with the Oslo team. I know it came up a few years ago, but I can't remember why it never happened. Probably I just never followed up.
I have added the openstack-vuln-mgmt team to most of the Oslo projects. I apparently don't have permission to change settings in oslo.policy, oslo.windows, and taskflow, so I will need help with that. After going through all of the projects, my guess is that the individual people who have access to the private security bugs are the ones who created the project in the first place. I guess that's fine, but there's an argument to be made that some of those should be cleaned up too.
I also noticed that oslo-coresec is not listed in most of the projects. Is there any sort of global setting that should give coresec memebers access to private security bugs, or do I need to add that to each project?
On 2021-03-26 16:52:52 -0500 (-0500), Ben Nemec wrote: [...]
I have added the openstack-vuln-mgmt team to most of the Oslo projects.
Great, happy to help there.
I apparently don't have permission to change settings in oslo.policy,
This is maintained by oslo-policy-core which has Adam as its owner and only administrator, so he's currently the only one who can add more members to that group though any one of the group members could help us by switching the oslo.core maintainer to some other group owned by openstack-admins if Adam can't be reached to make openstack-admins the owner of oslo-policy-core.
oslo.windows,
Similarly, maintainer is oslo-windows-drivers which has Claudiu as its owner and only administrator, but the project maintainer could optionally be adjusted to another group by Alessandro if Claudiu can't be reached.
and taskflow,
Maintained by the taskflow-dev group for which Joshua is the owner and only administrator, but there are a lot of group members one of whom could switch the project maintainer for you.
so I will need help with that. After going through all of the projects, my guess is that the individual people who have access to the private security bugs are the ones who created the project in the first place. I guess that's fine, but there's an argument to be made that some of those should be cleaned up too.
In all three cases, I expect the people who have access to these are no longer active in OpenStack, so yes getting them fixed would be a "good idea."
I also noticed that oslo-coresec is not listed in most of the projects. Is there any sort of global setting that should give coresec memebers access to private security bugs, or do I need to add that to each project?
You'd have to add it separately to each of them, yes. Though for any with VMT oversight, we suggest you not do that and instead let one of the vulnerability coordinators subscribe your security reviewer group after we've confirmed the report isn't misdirected at the wrong project, in order to minimize unnecessary initial spread of sensitive information.
participants (2)
-
Ben Nemec
-
Jeremy Stanley