Improper handling of ScaleIO backend credentials

Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions.

In keeping with recent OpenStack vulnerability management policy changes, no report should remain under private embargo for more than 90 days. Because this report predates the change in policy, the deadline for public disclosure is being set to 90 days from today. If the report is not resolved within the next 90 days, it will revert to our public workflow as of 2020-05-27. Please see http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012721.html for further details.

It doesn't look like this report has seen any activity since my update two months ago, so consider this a friendly reminder:

The embargo for this report is due to expire one month from today, on May 27, and will be switched public on or shortly after that day if it is not already resolved sooner.

Thanks!

Checking with the team, it sounds like this may be a limitation with how this storage works. Whether the product can be changed to address this has yet to be determined. The "fix" for this may end up needing to be a documentation update alerting operators that this is a concern they need to be aware of.

It sounds like this could wind up being a class B1 report (can only be fixed in master) like related bug 1736773, or B2 (vulnerability without a complete fix yet, security note for all versions):

https://security.openstack.org/vmt-process.html#incident-report-taxonomy

If we can get some confirmation that there's unlikely to be any backportable fix on the way, then we may as well switch this to public ahead of the embargo expiration rather than delaying further. Thanks for checking!

VxFlex OS does not support multi-tenancy or per-volume authentication yet. We suggest to eliminate passing credentials from Cinder to Nova and storing them in “block_device_mapping” so that users won’t see any. Instead a separate file will be placed on each host. It will contain the same backend credentials parameters from similar sections in cinder.conf, e.g.

[vxflexos-1]
san_password = password1

[vxflexos-2]
san_password = password2
replication_san_password = replication_password2

Whenever Nova tries to connect a block device it will get the storage credentials from the file.

If I'm reading correctly, the proposed fix will require configuration changes for existing deployments, so we'll likely want a security note (OSSN) for this but we would not produce an advisory (OSSA).

@Jeremy and other VMT people: Now that it looks like we're closing in on a solution, how can we handle this? It would be good if we could give operators a heads up before the OSSN is published, because until they both have os-brick patched on all computes and the config file deployed on all hosts with a new password, they can't really fix this (except to change the password early so that no new connections to the backend can be made, which would be pretty disruptive). The statement in the description says "This embargo shall not extend past 2020-05-27 and will be made
public by or on that date if no fix is identified" -- since a fix has been identified, can we extend the embargo a bit?

It was meant to read "will be made public by or on that date EVEN if no fix is identified" since the policy change linked in my accompanying comment says:

    Embargoes for privately-reported vulnerabilities shall not last
    more than 90 days, except under unusual circumstances. Following
    the embargo expiration, reports will be publicly visible
    regardless of whether an advisory has been issued.

(now published at https://governance.openstack.org/tc/reference/tags/vulnerability_managed.html#requirements )

We also don't have any process identified for notifying consumers privately to make configuration changes; our OSSA process is focused on applying patches since the primary audience is downstream package maintainers for distributions (though we do have some large public cloud operators subscribed to receive advance copies of those patches for evaluation as well). In the past our policy for fixes requiring configuration changes has been to make them public as quickly as possible so that all operators/users can apply mitigations sooner.

That said, the embargo expiration policy does carve out an exception for "unusual circumstances" and we could attempt to reuse our pre-OSSA notification channel for OSSN guidance (I think it's been done once, several years ago). I still wonder why we need an exception here, since the report sat ignored for 10 months and saw no activity until it was nearing the new embargo expiration. If it wasn't critical enough for anyone to even comment on for nearly a year, is it really so critical that we need to continue to keep it a secret now? And if so, how long past May 27 do you propose extending it the embargo? Three days? A week?

os-brick patch:
Passes py36,37,38 tests
pep8 problem:
./os_brick/tests/initiator/connectors/test_scaleio.py:49:28: E241 multiple spaces after ':'
            'config_group': 'test',
(please fix or we'll have trouble when we try to merge this)

cinder patch:
passes pep8, py36,37,38, docs, functional-py36,38, pylint
Doc changes look OK, though someone who knows more triple-O should verify the text in the "Using VxFlex OS Storage with a containerized overcloud" section.

I think the code looks OK, but definitely need more eyes on this.

Other things to consider: Is this patch backportable (at least as far as stable/stein)? Can someone draft the intended configuration guidance to operators which would be necessary for an OSSN? I assume there's not much point to a typical DevStack+Tempest run with it, but does it still work on the VXFlexOS third-party CI environment with no test regressions?

Thanks, Jeremy, those are all good points. Here are my thoughts, though I encourage other members of cinder coresec to add comments:

> Is this patch backportable (at least as far as stable/stein)?

It should be a clean backport, plus the change is isolated to vxflexos/scaleio components in both cinder and os-brick, so it would be a very low risk of destabilizing deployments not using that backend.

> Can someone draft the intended configuration guidance to operators which would be necessary for an OSSN?

I can do this as soon as we've reached agreement that this is the correct fix, unless someone at Dell/EMC would prefer to do it. (I think the configuration guidance in the docs change in the cinder patch is very clear.)

> I assume there's not much point to a typical DevStack+Tempest run with it, but does it still work on the VXFlexOS third-party CI environment with no test regressions?

Ivan or someone from the Dell/EMC team: please leave some details about your testing on this patch so we have a record that it doesn't cause a regression. Bonus points if you can provide some indication that it works, e.g., nova bdm record without the password showing, calls to the Block Storage Attachments API showing no password, etc.

If I read the os-brick patch correctly, it is going to have brick read the username password from a config file. just a reminder that this wont work in the case of a user attaching a volume to a bare metal host unless the user has that password config file available as well. cinder client uses os-brick locally during a user attach from a BM host via the python brick cinder client extension. https://github.com/openstack/python-brick-cinderclient-ext

Hi, thanks all for comments/reviews.
> ./os_brick/tests/initiator/connectors/test_scaleio.py:49:28: E241 multiple spaces
Fixed, new patch is attached with the same name.

> just a reminder that this wont work in the case of a user attaching a volume to a bare metal host unless the user has that password config file available as well.
VxFlex OS volumes attach/detach operations do not work out of the box. To attach volume to bare metal host we need to install VxFlexx OS SDC component and create password file.

> Ivan or someone from the Dell/EMC team: please leave some details about your testing on this patch so we have a record that it doesn't cause a regression. Bonus points if you can provide some indication that it works, e.g., nova bdm record without the password showing, calls to the Block Storage Attachments API showing no password, etc.
Attached archive with tempest logs and screenshot from mysql block_device_mapping table.

So the security issue will still continue when users need to attach volumes to the BM host.

Good point, Walt. It sounds like we will have to recommend that vxflexos/scaleio not be used with bare metal, because all an attacker would have to do is boot a BM host, and they can obtain the credentials for the entire backend.

Ivan, do you see any way around that?

Sorry, can not understand the problem.
Can you give me more details?

Do you mean Ironic-like cases with normal user BMs? It should not be allowed with the storage. Any host that needs connection to the VxFlex OS storage must have client side software installed and configured as superuser. And for OpenStack there is now additional requirement of the config file with admin credentials. Client side VxFlex software creates virtual block devices on hosts that are passed to VMs.

So I would say no user BMs are supported / recommended. VMs are welcome.

Vladislav: thanks for confirming.

Ivan: I looked at the tarfile, but the tempest.log is really hard to read about what tests were run and the results. Could you send the console log, or whatever would show that? What I mean is something like:

https://ftp.nimblestorage.com/openstack_ci/iscsi/83/730183/1/check/nimble-iscsi-driver-dsvm-volume/32f9c4e/console.out

About halfway through that file you can see the tempest regex filter being used and then the results of the individual tests. Something like that would be really helpful.

As it stands now, this report is still scheduled to switch from Private Security to Public Security tomorrow with the expiration of its embargo. Do we have a reason to extend the embargo and keep it private for longer? This seems to be the current status:

1. There is a solution proposed where, once two patches are applied (comment #6 and comment #15), the operator can configure a safe operating mode for use with virtual server instances.

2. There is no identified solution for using this driver with bare metal instances, nor does one seem to be possible due to the design of the storage platform itself, so the guidance to operators is to not combine them (comment #20).

3. Tests of the proposed patch have been performed in a suitable lab environment, but sufficient evidence has not been provided for reviewers to confirm it's working to their satisfaction (comment #21).

4. Backports of the proposed patch to stable branches have not been provided yet, but it's expected to be trivial to cherry-pick and the implementation is presumed to meet OpenStack's stable branch policy (comment #13).

5. There was a suggestion that users of the driver should be provided an advance copy of the patches and configuration guidance so they will have time to secure their environments before the bug becomes public (comment #9).

If we were to extend the embargo on this report by a week, say to June 3, would that be enough time to address these points? Or will switching to public tomorrow (so patches can be pushed to Gerrit for broader review, more readable third-party test results can be generated and linked, et cetera) be preferable?

Jeremy, thanks for the update. If we can extend the embargo to June 3, that will be extremely helpful. While drafting the OSSN, I realized that the backports will not be as easy as I thought. To be specific, this problem applies to all stable branches, and we have a rename and some refactoring to deal with. So instead of having a single patch that could be applied to multiple releases, we're going to need multiple patches. The extra time would enable us to have these all ready for operators. I'll provide the details in another comment.

Draft of the OSSN for this issue attached.

Here's why the details in the OSSN patch are a TODO:

Cinder changes
--------------
"vxflexos" driver
master, ussuri: current cinder.patch attached to this bug
change to cinder/volume/drivers/dell_emc/vxflexos/rest_client.py
change to cinder/volume/drivers/dell_emc/vxflexos/driver.py

train: no rest client, all changes to be made to cinder/volume/drivers/dell_emc/vxflexos/driver.py

"scaleio" driver
pike, queens, rocky, stein: changes to cinder/volume/drivers/dell_emc/scaleio/driver.py
ocata: will need a different patch for cinder/volume/drivers/dell_emc/scaleio/driver.py due to refactoring in rocky

os-brick changes
----------------
Component was not renamed, so all scaleio.

os_brick/initiator/connectors/scaleio.py
looks like same change in
pike, queens, rocky, stein, train, ussuri, master

os_brick/privileged/scaleio.py
introduced in stein
ocata, pike, queens, rocky: doesn't exist

Vladislav and Ivan: Please get the info requested in comment #21 so we can verify that the patch isn't causing regressions. Once we're sure that patch will work, you'll need to put up some more branch-specific patches as noted in comment #25.

After discussing with the other members of the OpenStack VMT, we've agreed bumping the embargo expiration out an additional week should be fine, so I've updated it to June 3.

After reading through, it seems this flaw is CVE-worthy (vs an OSSN / hardening). The main security point is that a user can retrieve their own volume's connection information and then use it to access another user's volume/info.

Per Brian's draft OSSN notes: "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."

Will the OpenStack VMT move this to a CVE (OSSA)? Or is there a reason to see/keep this flaw at the hardening level?

Sorry for delayed response, had some issues with the environment.
Tempest logs from stable/ussuri with security patch attached.
Working now on backports.

Summer: To be handled as an advisory, the patches provided would need to completely fix the flaw, not merely allow an operator to configure the environment so that the flaw was no longer present. Basically we'd need agreement of the driver and Cinder/Brick maintainers as well as the OpenStack stable branch reviewers that such a default behavior change is appropriate to backport to all supported stable branches. In this case, I think it basically means a violation of OpenStack's typical stable branch policies because there would be new configuration settings required for the deployment, effectively breaking the storage backend until they were set. If the vulnerability is so severe that stable deployments are better off taken down until they can be reconfigured, then we should discuss this option further (I just wish people were interested enough in securing this nearly a year ago when the vulnerability was reported rather than waiting until the VMT was ready to make it public so that concerned users could at least stop using this long-vulnerable driver).

Train patches for os-brick/cinder with tempest logs attached.

Just noticed a typo in comment #25:

when I said:
"ocata: will need a different patch for cinder/volume/drivers/dell_emc/scaleio/driver.py due to refactoring in rocky"

I meant "refactoring in pike".

Hi Jeremy, absolutely agree that this could have been dealt with sooner. That said, my comment was that the flaw is serious enough to be categorized as a CVE, regardless of how it's dealt with. The patch will at least offer a mitigation. Will you be asking mitre for a CVE? RH can do that once it's public if you want.

Stein patch is ready.

Summer: Unless the plan changes to provide patches which fix this vulnerability for existing configurations or by breaking deployments until updated configuration is applied, which is likely even impossible for anyone who's been using the driver with bare metal instances unless the vendor alters the design of their product, the OpenStack VMT won't be issuing an advisory; and we only request CVEs from MITRE if an advisory is being drafted.

Publication of guidance to deployers and distributors for securing the software is still encouraged--we have a less formal "security note" process we recommend for this purpose--and if you wish to assign a CVE along with it then feel free to do so. All we ask is that you update this bug report with the CVE identifier so that multiple organizations don't do the same and wind up with duplicate CVEs.

According to the stable branch policy [0], "OpenStack Vulnerability Management will be reasonable efforts only" for branches in Extended Maintenance mode.

The following cinder and os-brick branches are in EM mode:
- ocata
- pike
- queens
- rocky

I think it is reasonable to push this fix as far back as Queens.

Ocata will take unreasonable effort. The requirements team was able to make some changes to get their Ocata gate moving again so they could push some requirements changes to hopefully unblock everyone else, but it hasn't worked for cinder [1] and os-brick [2], at least, and there seems to be a consensus building on the mailing list that Ocata needs to go EOL [3]. So I will declare right now we do not need to prepare an Ocata patch for this bug.

I'm willing to hear opinions about Pike (my personal opinion is that it is *not* reasonable effort). Right now, the cinder [4] and os-brick [5] gates are broken. The word on the street is that it can be fixed by modifying some of the test jobs to native zuul v3 jobs, but I haven't looked into it because the last change to cinder:stable/pike was 6 months ago, and the last change to os-brick:stable/pike was over 1 year ago. I am dubious that we will get the cinder/os-brick Pike gates working before 3 June (the PTG is next week, which basically leaves us tomorrow to get the gates fixed, and I would rather spend the time reviewing and getting the patches in place for Queens through master (Victoria). Further, there has not been a lot of interest in Pike (as evidenced by lack of backport activity), so I think it makes sense not to put effort into making a patch available for Pike.

So, to be completely clear:
* Ocata - no patch
* Pike - I'm inclined to say no patch, but am interested in other opinions.
* Queens through Victoria - we should have patches available

[0] https://docs.openstack.org/project-team-guide/stable-branches.html#extended-maintenance
[1] https://review.opendev.org/730938
[2] https://review.opendev.org/#/c/731193/
[3] http://lists.openstack.org/pipermail/openstack-discuss/2020-May/015112.html
[4] https://review.opendev.org/730959
[5] https://review.opendev.org/731196

There's also the option of just getting the backports through stable/stein ready to push at the same time an OSSN is published, and let any interested parties backport to older branches afterward. If you do mention EM branch commits, the way the VMT usually phrases it is along the lines of, "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."

Rocky patches.

I agree with Brian's assessment.

We just need Queens yet, and we should be ready to move ahead.

If we can get a patch for Pike, great. If that becomes too difficult due to code changes or other factors, I think we're fine.

Ocata is definitely too old and is likely to go EOL soon. Again, if a patch is available, that's a bonus. But I don't see that as a requirement.

I'll update the OSSN draft later today and get these patches reviewed (though of course, everyone should feel free to review/test them!).

With the PTG next week, we should figure out the timing of this. Jeremy, can you suggest how this should go?

rosmaita
- git review of OSSN-0086 <-- what time should I submit this?
- after it is approved, will paste the text into the wiki and send a message to the ML

pcheli
- have patched local branches set up so that you can do 'git review' from each one
- should there be a patch directly to ussuri, or will we backport the patch from master?
- rosmaita and smcginnis - be available to approve patches as they are proposed

Ivan, what time zone are you in?

Moscow (UTC+3).

Brian: Basically whatever time you, Ivan and Sean are comfortable doing it should be fine. Just switch this bug from Private Security to Public first and add the "security" bugtag to it. That way if you include a Closes-Bug: #1823200 as a commit message footer for the various changes, this bug and the security ML should get updated automatically with links to them. I've marked the OSSN project as affected to it will get a bugtask, and assigned it to you. I recommend pushing the security-doc change around the same time as the cinder/os-brick changes. Your plan in comment #40 looks great, though if there is no convenient time overlap between you and Ivan, some delay between those is likely fine too. I probably wouldn't send the announcement about it to the ML until the related changes merge to affected branches you're listing, since interested parties may take that as a queue to pull updated branches immediately to obtain those patches.

I've also added the security guide and os-brick projects as affected since there will be changes getting pushed for those, but you also may want to add series bugtasks for each of the cinder and os-brick branches getting backports so they're tracked too.

Thanks, Jeremy. I'll update the series info on this bug.

Draft of a release note for cinder master. Please review, and I will generate them for the remaining branches (they all reference different versions of os-brick) once we have agreed on the wording. Will also need something similar for os-brick, will post something soon.

Draft of os-brick release note.

Updated release note for master attached. (There was an error in the markup.)

@pcheli: I'm sorry for not mentioning this sooner, but I think you need to increment the version number and version history on the driver in each branch so that it will be easy for operators to tell if they are using a fixed driver or not. Just be sure to pick a number that won't conflict with a more recent branch (e.g., stein is at 2.0.4 and a 2.0.5 was already included in train.

Maybe Sean or someone can suggest the best way to handle this. I'm not sure if you can make the new stein driver 2.1.4 or whether you should make it 2.0.5.1

Brian,
Ok, I’ll prepare patches for each branch and will be ready to push them on June 3.
Ex. 2.0.5.1 will be good I think.
But for master branch I suggest to use 3.5.4.
Also do I need to include fix details in description for driver version or just bug number will be sufficient?

Ivan,

I think it would be sufficient to say "Fix for Bug #1823200. See OSSN-0086 for details."

Patches look ok (except for the versioning issue mentioned above).

Applied the patches and ran local tests:
patch for master
cinder: passed pep8, py36, py37, py38, docs, functional-py36, functional-38, pylint
os-brick: passed pep8, py36,37,38

--
ussuri: applied master patch to stable/ussuri
cinder: passed pep8, py37, functional-py37
os-brick: passed pep8, py37
--
patch for train
cinder: passed: pep8,py27,py36,py37,docs,functional-py36
os-brick: passed: pep8,py27,py36,py37,docs

--
patch for stein
cinder: pep8,py27,py36,functional-py36,docs
os-brick: passed: pep8,py27,py36,py37

---
patch for rocky
cinder: passed: pep8,py27,py35,py36,functional-py35,functional-py36,docs
os-brick: passed: pep8,py27,py35,docs

Attached release notes for cinder/os-brick master, ussuri, train, stein. (It's a tarball of files, not patches.)

All above mentioned patches are ready for pushing to gerrit with versioning added.
Testing Queens patch now.

Here's what I think about the ordering of this. We want there to be as little time between steps as possible.

(0) Make https://bugs.launchpad.net/cinder/+bug/1823200 public.

(1) Propose all os-brick patches, even ussuri. If you rebase before pushing the patches, we won't need merge commits, and I can get the release patches ready sooner. Don't forget to include the release note for each branch (attached to the Launchpad bug) and "Closes-bug: #1823200" in the commit message.

(2) Also propose the cinder patches. Include the release note and "Closes-bug" as above. We won't be able to merge them yet because they won't pass Dell-EMC CI until we update the requirements.txt and lower-constraints.txt (which we can't do until the new os-brick releases happen).

(3) Once all patches are posted, I'll update the OSSN with the gerrit urls, put up a security-doc patch, and update the OSSN in the wiki. Even if the patches haven't merged yet, they will be available for operators to look at and start planning. So I guess at this point I also send the OSSN to openstack-discuss and openstack-announce?

(4) I'll post release patches for all os-brick branches as soon as the patches in (1) have merged.

(5) The release patches will trigger an upper-constraints update. We can ask Sean to line up another requirements person in addition to himself to approve those patches. (We won't be able to merge the cinder change in any branch until the upper-constraints has changed, but at least the patches will be available.)

(6) Update the requirements.txt and lower-constraints.txt in each of (2). (I'm thinking that I'll probably do this because it will be late in UTC+3 at this point, but we can work that out.) I'll have to line up two other people in cinder coresec to approve.

(7) After all (6) have merged, I'll propose cinder releases.

And I think that's it?

Got it.
Do we need release notes also for Rocky and Queens?

Brian: Your sequence in comment #55 should work, just bear in mind that OSSNs traditionally haven't linked to specific changes in Gerrit like OSSAs because they're usually not published/announced until after all related changes have merged. Since the "patches" section of your proposed OSSN includes that information, it should be fine for this particular case.

Brian: Also, on step #0 there, when you make the bug public you should first remove the initial paragraph from the description (so that we don't have a public bug claiming to be under embargo), then switch the bug status from Private Security to Public (not Public Security since we generally only use that for advisories not notes) and add a "security" bugtag so that the openstack-security ML will get a copy of the bug updates from that point forward (patches proposed for review, patches mwerged, releases containing them, further discussion, et cetera).

@Ivan: no release notes for Rocky & Queens because there won't be any releases from those. I think there's sufficient info in the doc updates on the cinder patch + the OSSN so that operators will know what to do. Plus there are the release notes on the more recent patches they can use for reference.

@Ivan: also, about timing. Can you arrange to push the patches to gerrit around 2pm your time and then put a message into #openstack-cinder tagging rosmaita geguileo whoami-rajat eharney smcginnis to let us know that the patches are ready for review.

@Ivan: also, i will update the tarball of release notes today; will make sure it says "new" in the filename so you can tell they're updated (we had a security meeting and some clarifications were suggested).

Thanks!

Updated OSSN, still needs patch urls.

Updated OSSN; still needs patch urls.

Release notes for cinder and os-brick for victoria (master), stein, train, and ussuri.

@Brian no problem.

Fix proposed to branch: stable/queens
Review: https://review.opendev.org/733110

Reviewed: https://review.opendev.org/733098
Committed: https://git.openstack.org/cgit/openstack/os-brick/commit/?id=5414305a2b2c776be62b695c4144dd4ace7f5b30
Submitter: Zuul
Branch: master

commit 5414305a2b2c776be62b695c4144dd4ace7f5b30
Author: Ivan Pchelintsev <email address hidden>
Date: Mon Jun 1 11:28:08 2020 +0300

    Remove VxFlex OS credentials from connection_properties

    VxFlex OS password is not stored in block_device_mapping table. Instead of this
    passwords are stored in separate file and are retrieved during each attach/detach
    operation.

    Closes-Bug: #1823200
    Change-Id: Iab54c515fe7be252df52b1a0503a251779805759

Reviewed: https://review.opendev.org/733099
Committed: https://git.openstack.org/cgit/openstack/os-brick/commit/?id=a1c9f649448bc91325b0735c48e780cce44df2c1
Submitter: Zuul
Branch: stable/ussuri

commit a1c9f649448bc91325b0735c48e780cce44df2c1
Author: Ivan Pchelintsev <email address hidden>
Date: Mon Jun 1 11:41:50 2020 +0300

    Remove VxFlex OS credentials from connection_properties

    VxFlex OS password is not stored in block_device_mapping table. Instead of this
    passwords are stored in separate file and are retrieved during each attach/detach
    operation.

    Closes-Bug: #1823200
    Change-Id: Iaa337518d6e6542a93d9e4f5d4d72094e9279c53

Reviewed: https://review.opendev.org/733100
Committed: https://git.openstack.org/cgit/openstack/os-brick/commit/?id=55fc99852166f72b95d85dc917197f5544861e7c
Submitter: Zuul
Branch: stable/train

commit 55fc99852166f72b95d85dc917197f5544861e7c
Author: Ivan Pchelintsev <email address hidden>
Date: Mon Jun 1 11:51:54 2020 +0300

    Remove VxFlex OS credentials from connection_properties

    VxFlex OS password is not stored in block_device_mapping table. Instead of this
    passwords are stored in separate file and are retrieved during each attach/detach
    operation.

    Closes-Bug: #1823200
    Change-Id: Ia1d2b2151e5676037d40bfaf388b54023fc37093

Reviewed: https://review.opendev.org/733102
Committed: https://git.openstack.org/cgit/openstack/os-brick/commit/?id=b5891702cc24b0c9cedf6961d3223a37830341b9
Submitter: Zuul
Branch: stable/stein

commit b5891702cc24b0c9cedf6961d3223a37830341b9
Author: Ivan Pchelintsev <email address hidden>
Date: Mon Jun 1 11:59:06 2020 +0300

    Remove VxFlex OS credentials from connection_properties

    VxFlex OS password is not stored in block_device_mapping table. Instead of this
    passwords are stored in separate file and are retrieved during each attach/detach
    operation.

    Closes-Bug: #1823200
    Change-Id: I89bd58d79e5cd74cf283d026ada486b7f7122980

Reviewed: https://review.opendev.org/733103
Committed: https://git.openstack.org/cgit/openstack/os-brick/commit/?id=88fbec6b1d8ac9a0f8f259a825e6139781021e3f
Submitter: Zuul
Branch: stable/rocky

commit 88fbec6b1d8ac9a0f8f259a825e6139781021e3f
Author: Ivan Pchelintsev <email address hidden>
Date: Mon Jun 1 12:11:19 2020 +0300

    Remove VxFlex OS credentials from connection_properties

    VxFlex OS password is not stored in block_device_mapping table. Instead of this
    passwords are stored in separate file and are retrieved during each attach/detach
    operation.

    Closes-Bug: 1823200
    Change-Id: I10a8aaddbf7dd09830cd4189cd1f99c0ad1f3b60

Reviewed: https://review.opendev.org/733104
Committed: https://git.openstack.org/cgit/openstack/os-brick/commit/?id=72c63681178286ed9cd1e1ab48969a64b9004d7c
Submitter: Zuul
Branch: stable/queens

commit 72c63681178286ed9cd1e1ab48969a64b9004d7c
Author: Ivan Pchelintsev <email address hidden>
Date: Tue Jun 2 16:23:04 2020 +0300

    Remove VxFlex OS credentials from connection_properties

    VxFlex OS password is not stored in block_device_mapping table. Instead of this
    passwords are stored in separate file and are retrieved during each attach/detach
    operation.

    Closes-Bug: #1823200
    Change-Id: Ib7778ba9d38a68d8b56ca632c5f1c353d55830b0

Reviewed: https://review.opendev.org/733116
Committed: https://git.openstack.org/cgit/openstack/security-doc/commit/?id=fade732411e3d349a49859fb7e9c3d89830ed792
Submitter: Zuul
Branch: master

commit fade732411e3d349a49859fb7e9c3d89830ed792
Author: Brian Rosmaita <email address hidden>
Date: Wed Jun 3 07:36:48 2020 -0400

    Add OSSN-0086

    Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure

    Closes-bug: #1823200
    Change-Id: I497c2ba8e297f9463f36313587de358cb1fde0ed

The Red Hat Product Security team has filed CVE-2020-10755 for this issue.

Fix proposed to branch: stable/pike
Review: https://review.opendev.org/733615

Reviewed: https://review.opendev.org/733106
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=20a3cab7ddd9555eaa0406f539d491308f18e4e9
Submitter: Zuul
Branch: stable/ussuri

commit 20a3cab7ddd9555eaa0406f539d491308f18e4e9
Author: Ivan Pchelintsev <email address hidden>
Date: Mon Jun 1 11:43:20 2020 +0300

    Remove VxFlex OS credentials from connection_properties

    VxFlex OS password is not stored in block_device_mapping table. Instead of this
    passwords are stored in separate file and are retrieved during each attach/detach
    operation.

    Closes-Bug: #1823200
    Change-Id: I99de0b618d4ead78f921fde296cee4c7484387dd

Reviewed: https://review.opendev.org/733110
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=89bdebd2a92f83a199c86855a63fd3deab9a489c
Submitter: Zuul
Branch: stable/queens

commit 89bdebd2a92f83a199c86855a63fd3deab9a489c
Author: Ivan Pchelintsev <email address hidden>
Date: Tue Jun 2 16:36:53 2020 +0300

    Remove VxFlex OS credentials from connection_properties

    VxFlex OS password is not stored in block_device_mapping table.
    Instead of this passwords are stored in separate file and are
    retrieved during each attach/detach operation.

    The stable/queens branch is in Extended Maintenance mode and is no
    longer released from. If you decide to apply this patch to your
    deployment, you must make a corresponding change to the os-brick
    library. You can find the os-brick patch for stable/queens here:
        https://review.opendev.org/#/c/733104

    Additionally, you must deploy a new configuration file on compute
    nodes, cinder nodes, and anywhere you would perform a volume
    attachment in your deployment. See the documentation change on
    this patch for details about the new config file.

    See OSSN-0086 for more information about this change:
        https://wiki.openstack.org/wiki/OSSN/OSSN-0086

    Closes-Bug: #1823200
    Change-Id: I831321d12a6df2b950f05e2452710b9ae105ada4

Fix proposed to branch: stable/pike
Review: https://review.opendev.org/733662

Reviewed: https://review.opendev.org/733105
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=b2c9592281b24824c2158f91a9295288f41dd81a
Submitter: Zuul
Branch: master

commit b2c9592281b24824c2158f91a9295288f41dd81a
Author: Ivan Pchelintsev <email address hidden>
Date: Mon Jun 1 11:32:38 2020 +0300

    Remove VxFlex OS credentials from connection_properties

    VxFlex OS password is not stored in block_device_mapping table. Instead of this
    passwords are stored in separate file and are retrieved during each attach/detach
    operation.

    Closes-Bug: #1823200
    Change-Id: Ia7cc17472677a693c6162f0b8b0529df62eed7cf

Reviewed: https://review.opendev.org/733108
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=25ed65f1fa1d50cf3d5f757736b6cfb506ce402f
Submitter: Zuul
Branch: stable/stein

commit 25ed65f1fa1d50cf3d5f757736b6cfb506ce402f
Author: Ivan Pchelintsev <email address hidden>
Date: Mon Jun 1 12:00:50 2020 +0300

    Remove VxFlex OS credentials from connection_properties

    VxFlex OS password is not stored in block_device_mapping table. Instead of this
    passwords are stored in separate file and are retrieved during each attach/detach
    operation.

    Closes-Bug: #1823200
    Change-Id: I3f6bfe360491c295bdb81008c31ad2d4e3305736

Reviewed: https://review.opendev.org/733107
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=aadf0950c9c62f68a107c89c5b7c7632a2c732db
Submitter: Zuul
Branch: stable/train

commit aadf0950c9c62f68a107c89c5b7c7632a2c732db
Author: Ivan Pchelintsev <email address hidden>
Date: Mon Jun 1 11:50:01 2020 +0300

    Remove VxFlex OS credentials from connection_properties

    VxFlex OS password is not stored in block_device_mapping table. Instead of this
    passwords are stored in separate file and are retrieved during each attach/detach
    operation.

    Closes-Bug: #1823200
    Change-Id: Ie9c41f37ab5c186b9f9aa92539a363d0b2388035

Reviewed: https://review.opendev.org/733109
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=c427484d75e276aa02dcd7586e2f8bed3780878c
Submitter: Zuul
Branch: stable/rocky

commit c427484d75e276aa02dcd7586e2f8bed3780878c
Author: Ivan Pchelintsev <email address hidden>
Date: Mon Jun 1 12:12:53 2020 +0300

    Remove VxFlex OS credentials from connection_properties

    VxFlex OS password is not stored in block_device_mapping table.
    Instead of this passwords are stored in separate file and are
    retrieved during each attach/detach operation.

    The stable/rocky branch is in Extended Maintenance mode and is no
    longer released from. If you decide to apply this patch to your
    deployment, you must make a corresponding change to the os-brick
    library. You can find the os-brick patch for stable/rocky here:
        https://review.opendev.org/#/c/733103/

    Additionally, you must deploy a new configuration file on compute
    nodes, cinder nodes, and anywhere you would perform a volume
    attachment in your deployment. See the documentation change on
    this patch for details about the new config file.

    See OSSN-0086 for more information about this change:
        https://wiki.openstack.org/wiki/OSSN/OSSN-0086

    Closes-Bug: #1823200
    Change-Id: Ic115fbe455c00589e7b8e60eca91e979bac276ea

The attachment "cinder.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

This bug was fixed in the package cinder - 2:17.0.0~b1~git2020062409.85fcf1057-0ubuntu1

---------------
cinder (2:17.0.0~b1~git2020062409.85fcf1057-0ubuntu1) groovy; urgency=medium

  * SECURITY UPDATE: Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure
    (LP: #1823200)
    - Remove VxFlex OS credentials from connection_properties. Passwords are
      now stored in separate file and are retrieved during each attach/detach
      operation. Cinder is patched in 16.1.0 stable point release.
    - d/control: Align (Build-)Depends with min version of python3-os-brick
      required to fix credential exposure.
    - CVE-2020-10755
  * New upstream snapshot for OpenStack Victoria.
  * d/control: Align (Build-)Depends with upstream.
  * d/p/py38skip.patch: Dropped. No longer needed.
  * d/p/skip-victoria-failures.patch: Rebased and updated with upstream bug.

 -- Corey Bryant <email address hidden> Wed, 24 Jun 2020 09:10:19 -0400

This bug was fixed in the package cinder - 2:17.0.0~b1~git2020062409.85fcf1057-0ubuntu1~cloud0
---------------

 cinder (2:17.0.0~b1~git2020062409.85fcf1057-0ubuntu1~cloud0) focal-victoria; urgency=medium
 .
   * New upstream release for the Ubuntu Cloud Archive.
 .
 cinder (2:17.0.0~b1~git2020062409.85fcf1057-0ubuntu1) groovy; urgency=medium
 .
   * SECURITY UPDATE: Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure
     (LP: #1823200)
     - Remove VxFlex OS credentials from connection_properties. Passwords are
       now stored in separate file and are retrieved during each attach/detach
       operation. Cinder is patched in 16.1.0 stable point release.
     - d/control: Align (Build-)Depends with min version of python3-os-brick
       required to fix credential exposure.
     - CVE-2020-10755
   * New upstream snapshot for OpenStack Victoria.
   * d/control: Align (Build-)Depends with upstream.
   * d/p/py38skip.patch: Dropped. No longer needed.
   * d/p/skip-victoria-failures.patch: Rebased and updated with upstream bug.
 .
 cinder (2:16.0.0-0ubuntu2) groovy; urgency=medium
 .
   * d/p/skip-victoria-failures.patch: Temporarily skipping groovy
     failures to unblock Ussuri.
 .
 cinder (2:16.0.0-0ubuntu1) groovy; urgency=medium
 .
   * d/watch: Update tarball version.
   * d/p/py38skip.patch: Refresh patch.
   * New upstream release for OpenStack Ussuri (LP: #1877642).
   * d/p/monkey-patch-original-current-thread.patch: Removed as it is
     merged into rc3 upstream.

Hello Eric, or anyone else affected,

Accepted cinder into train-proposed. The package will build now and be available in the Ubuntu Cloud Archive in a few hours, and then in the -proposed repository.

Please help us by testing this new package. To enable the -proposed repository:

  sudo add-apt-repository cloud-archive:train-proposed
  sudo apt-get update

Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-train-needed to verification-train-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-train-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Hello Eric, or anyone else affected,

Accepted python-os-brick into train-proposed. The package will build now and be available in the Ubuntu Cloud Archive in a few hours, and then in the -proposed repository.

Please help us by testing this new package. To enable the -proposed repository:

  sudo add-apt-repository cloud-archive:train-proposed
  sudo apt-get update

Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-train-needed to verification-train-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-train-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Hello Eric, or anyone else affected,

Accepted cinder into stein-proposed. The package will build now and be available in the Ubuntu Cloud Archive in a few hours, and then in the -proposed repository.

Please help us by testing this new package. To enable the -proposed repository:

  sudo add-apt-repository cloud-archive:stein-proposed
  sudo apt-get update

Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-stein-needed to verification-stein-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-stein-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Hello Eric, or anyone else affected,

Accepted python-os-brick into stein-proposed. The package will build now and be available in the Ubuntu Cloud Archive in a few hours, and then in the -proposed repository.

Please help us by testing this new package. To enable the -proposed repository:

  sudo add-apt-repository cloud-archive:stein-proposed
  sudo apt-get update

Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-stein-needed to verification-stein-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-stein-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Hello Eric, or anyone else affected,

Accepted cinder into rocky-proposed. The package will build now and be available in the Ubuntu Cloud Archive in a few hours, and then in the -proposed repository.

Please help us by testing this new package. To enable the -proposed repository:

  sudo add-apt-repository cloud-archive:rocky-proposed
  sudo apt-get update

Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-rocky-needed to verification-rocky-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-rocky-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Hello Eric, or anyone else affected,

Accepted python-os-brick into rocky-proposed. The package will build now and be available in the Ubuntu Cloud Archive in a few hours, and then in the -proposed repository.

Please help us by testing this new package. To enable the -proposed repository:

  sudo add-apt-repository cloud-archive:rocky-proposed
  sudo apt-get update

Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-rocky-needed to verification-rocky-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-rocky-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Fix proposed to branch: stable/pike
Review: https://review.opendev.org/739545

Change abandoned by Sean McGinnis (<email address hidden>) on branch: stable/pike
Review: https://review.opendev.org/739545
Reason: https://review.opendev.org/#/c/733662/

This bug was fixed in the package python-os-brick - 3.0.1-0ubuntu1.2

---------------
python-os-brick (3.0.1-0ubuntu1.2) focal-security; urgency=medium

  * d/gbp.conf: Create stable/ussuri branch.
  * SECURITY UPDATE: Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure
    (LP: #1823200)
    - debian/patches/CVE-2020-10755.patch: Remove VxFlex OS credentials
      from connection_properties. Passwords are now stored in separate file
      and are retrieved during each attach/detach operation.
    - CVE-2020-10755

 -- Corey Bryant <email address hidden> Mon, 08 Jun 2020 09:25:57 -0400

This bug was fixed in the package python-os-brick - 2.3.0-0ubuntu1.2

---------------
python-os-brick (2.3.0-0ubuntu1.2) bionic-security; urgency=medium

  * d/gbp.conf: Create stable/queens branch.
  * SECURITY UPDATE: Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure
    (LP: #1823200)
    - debian/patches/CVE-2020-10755*.patch: Remove VxFlex OS credentials
      from connection_properties. Passwords are now stored in separate file
      and are retrieved during each attach/detach operation.
    - CVE-2020-10755

 -- Corey Bryant <email address hidden> Thu, 26 Apr 2018 13:34:33 -0400

This bug was fixed in the package cinder - 2:16.1.0-0ubuntu1

---------------
cinder (2:16.1.0-0ubuntu1) focal-security; urgency=medium

  [ Chris MacNaughton ]
  * New stable point release for OpenStack Ussuri (LP: #1883879).

  [ Corey Bryant ]
  * SECURITY UPDATE: Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure
    (LP: #1823200)
    - Remove VxFlex OS credentials from connection_properties. Passwords are
      now stored in separate file and are retrieved during each attach/detach
      operation. Cinder is patched in 16.1.0 stable point release.
    - d/control: Align (Build-)Depends with min version of python3-os-brick
      required to fix credential exposure.
    - CVE-2020-10755

 -- Corey Bryant <email address hidden> Tue, 23 Jun 2020 16:52:33 -0400

This bug was fixed in the package cinder - 2:12.0.9-0ubuntu1.2

---------------
cinder (2:12.0.9-0ubuntu1.2) bionic-security; urgency=medium

  * SECURITY UPDATE: Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure
    (LP: #1823200)
    - debian/patches/CVE-2020-10755.patch: Remove VxFlex OS credentials
      from connection_properties. Passwords are now stored in separate file
      and are retrieved during each attach/detach operation.
    - d/control: Align (Build-)Depends with min version of python3-os-brick
      required to fix credential exposure.
    - CVE-2020-10755

 -- Corey Bryant <email address hidden> Tue, 23 Jun 2020 15:58:12 -0400

Hello Eric, or anyone else affected,

Accepted python-os-brick into ussuri-proposed. The package will build now and be available in the Ubuntu Cloud Archive in a few hours, and then in the -proposed repository.

Please help us by testing this new package. To enable the -proposed repository:

  sudo add-apt-repository cloud-archive:ussuri-proposed
  sudo apt-get update

Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-ussuri-needed to verification-ussuri-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-ussuri-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Hello Eric, or anyone else affected,

Accepted cinder into ussuri-proposed. The package will build now and be available in the Ubuntu Cloud Archive in a few hours, and then in the -proposed repository.

Please help us by testing this new package. To enable the -proposed repository:

  sudo add-apt-repository cloud-archive:ussuri-proposed
  sudo apt-get update

Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-ussuri-needed to verification-ussuri-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-ussuri-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

The verification of the Stable Release Update for cinder has completed successfully and the package has now been released to -updates. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

This bug was fixed in the package cinder - 2:16.1.0-0ubuntu1~cloud0
---------------

 cinder (2:16.1.0-0ubuntu1~cloud0) bionic-ussuri; urgency=medium
 .
   * New upstream release for the Ubuntu Cloud Archive.
 .
 cinder (2:16.1.0-0ubuntu1) focal-security; urgency=medium
 .
   [ Chris MacNaughton ]
   * New stable point release for OpenStack Ussuri (LP: #1883879).
 .
   [ Corey Bryant ]
   * SECURITY UPDATE: Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure
     (LP: #1823200)
     - Remove VxFlex OS credentials from connection_properties. Passwords are
       now stored in separate file and are retrieved during each attach/detach
       operation. Cinder is patched in 16.1.0 stable point release.
     - d/control: Align (Build-)Depends with min version of python3-os-brick
       required to fix credential exposure.
     - CVE-2020-10755

The verification of the Stable Release Update for python-os-brick has completed successfully and the package has now been released to -updates. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

This bug was fixed in the package python-os-brick - 3.0.1-0ubuntu1.2~cloud0
---------------

 python-os-brick (3.0.1-0ubuntu1.2~cloud0) bionic-ussuri; urgency=medium
 .
   * New update for the Ubuntu Cloud Archive.
 .
 python-os-brick (3.0.1-0ubuntu1.2) focal-security; urgency=medium
 .
   * d/gbp.conf: Create stable/ussuri branch.
   * SECURITY UPDATE: Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure
     (LP: #1823200)
     - debian/patches/CVE-2020-10755.patch: Remove VxFlex OS credentials
       from connection_properties. Passwords are now stored in separate file
       and are retrieved during each attach/detach operation.
     - CVE-2020-10755

The verification of the Stable Release Update for cinder has completed successfully and the package has now been released to -updates. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

This bug was fixed in the package cinder - 2:15.2.0-0ubuntu1~cloud0
---------------

 cinder (2:15.2.0-0ubuntu1~cloud0) bionic-train; urgency=medium
 .
   [ Chris MacNaughton ]
   * New stable point release for OpenStack Train (LP: #1883892)
   * d/control: Align (Build-)Depends with upstream.
 .
   [ Corey Bryant ]
   * SECURITY UPDATE: Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure
     (LP: #1823200)
     - Remove VxFlex OS credentials from connection_properties. Passwords are
       now stored in separate file and are retrieved during each attach/detach
       operation. Cinder is patched in 15.2.0 stable point release.
     - d/control: Align (Build-)Depends with min version of python3-os-brick
       required to fix credential exposure.
     - CVE-2020-10755

The verification of the Stable Release Update for python-os-brick has completed successfully and the package has now been released to -updates. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

This bug was fixed in the package python-os-brick - 2.10.0-0ubuntu1~cloud0.1
---------------

 python-os-brick (2.10.0-0ubuntu1~cloud0.1) bionic-train; urgency=medium
 .
   * d/gbp.conf: Create stable/train branch.
   * SECURITY UPDATE: Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure
     (LP: #1823200)
     - debian/patches/CVE-2020-10755*.patch: Remove VxFlex OS credentials
       from connection_properties. Passwords are now stored in separate file
       and are retrieved during each attach/detach operation.
     - CVE-2020-10755

Eoan is EOL

The verification of the Stable Release Update for cinder has completed successfully and the package has now been released to -updates. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

This bug was fixed in the package cinder - 2:14.1.0-0ubuntu1~cloud0
---------------

 cinder (2:14.1.0-0ubuntu1~cloud0) bionic-stein; urgency=medium
 .
   [ Chris MacNaughton ]
   * New stable point release for OpenStack Stein (LP: #1884028).
 .
   [ Corey Bryant ]
   * SECURITY UPDATE: Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure
     (LP: #1823200)
     - Remove VxFlex OS credentials from connection_properties. Passwords are
       now stored in separate file and are retrieved during each attach/detach
       operation. Cinder is patched in 14.1.0 stable point release.
     - d/control: Align (Build-)Depends with min version of python3-os-brick
       required to fix credential exposure.
     - CVE-2020-10755

The verification of the Stable Release Update for cinder has completed successfully and the package has now been released to -updates. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

This bug was fixed in the package cinder - 2:13.0.9-0ubuntu1~cloud1.1
---------------

 cinder (2:13.0.9-0ubuntu1~cloud1.1) bionic-rocky; urgency=medium
 .
   * SECURITY UPDATE: Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure
     (LP: #1823200)
     - debian/patches/CVE-2020-10755.patch: Remove VxFlex OS credentials
       from connection_properties. Passwords are now stored in separate file
       and are retrieved during each attach/detach operation.
     - d/control: Align (Build-)Depends with min version of python3-os-brick
       required to fix credential exposure.
     - CVE-2020-10755
   * d/control: Add python3-sqlalchemy-utils Build-Depends to enable successful
     test execution.

The verification of the Stable Release Update for python-os-brick has completed successfully and the package has now been released to -updates. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

This bug was fixed in the package python-os-brick - 2.5.3-0ubuntu1~cloud0.1
---------------

 python-os-brick (2.5.3-0ubuntu1~cloud0.1) bionic-rocky; urgency=medium
 .
   * d/gbp.conf: Create stable/rocky branch.
   * SECURITY UPDATE: Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure
     (LP: #1823200)
     - debian/patches/CVE-2020-10755*.patch: Remove VxFlex OS credentials
       from connection_properties. Passwords are now stored in separate file
       and are retrieved during each attach/detach operation.
     - CVE-2020-10755

This bug was fixed in the package python-os-brick - 2.8.1-0ubuntu1~cloud0.1
---------------

 python-os-brick (2.8.1-0ubuntu1~cloud0.1) bionic-stein; urgency=medium
 .
   * d/gbp.conf: Create stable/stein branch.
   * SECURITY UPDATE: Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure
     (LP: #1823200)
     - debian/patches/CVE-2020-10755*.patch: Remove VxFlex OS credentials
       from connection_properties. Passwords are now stored in separate file
       and are retrieved during each attach/detach operation.
     - CVE-2020-10755

Hello Eric, or anyone else affected,

Accepted cinder into queens-proposed. The package will build now and be available in the Ubuntu Cloud Archive in a few hours, and then in the -proposed repository.

Please help us by testing this new package. To enable the -proposed repository:

  sudo add-apt-repository cloud-archive:queens-proposed
  sudo apt-get update

Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-queens-needed to verification-queens-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-queens-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

The verification of the Stable Release Update for cinder has completed successfully and the package has now been released to -updates. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

This bug was fixed in the package cinder - 2:12.0.9-0ubuntu1.2~cloud0
---------------

 cinder (2:12.0.9-0ubuntu1.2~cloud0) xenial-queens; urgency=medium
 .
   * New update for the Ubuntu Cloud Archive.
 .
 cinder (2:12.0.9-0ubuntu1.2) bionic-security; urgency=medium
 .
   * SECURITY UPDATE: Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure
     (LP: #1823200)
     - debian/patches/CVE-2020-10755.patch: Remove VxFlex OS credentials
       from connection_properties. Passwords are now stored in separate file
       and are retrieved during each attach/detach operation.
     - d/control: Align (Build-)Depends with min version of python3-os-brick
       required to fix credential exposure.
     - CVE-2020-10755

Reviewed: https://review.opendev.org/733615
Committed: https://git.openstack.org/cgit/openstack/os-brick/commit/?id=4047948f1ac8055a025972ad73ec3ec421450775
Submitter: Zuul
Branch: stable/pike

commit 4047948f1ac8055a025972ad73ec3ec421450775
Author: Ivan Pchelintsev <email address hidden>
Date: Tue Jun 2 16:23:04 2020 +0300

    Remove VxFlex OS credentials from connection_properties

    VxFlex OS password is not stored in block_device_mapping table. Instead of this
    passwords are stored in separate file and are retrieved during each attach/detach
    operation.

    Closes-Bug: #1823200
    Change-Id: Ib7778ba9d38a68d8b56ca632c5f1c353d55830b0
    (cherry picked from commit 72c63681178286ed9cd1e1ab48969a64b9004d7c)

Reviewed: https://review.opendev.org/733662
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=ba785eef5f515b869c0d68016e84bb74f76ab45e
Submitter: Zuul
Branch: stable/pike

commit ba785eef5f515b869c0d68016e84bb74f76ab45e
Author: Ivan Pchelintsev <email address hidden>
Date: Thu Jun 4 19:57:56 2020 +0300

    Remove VxFlex OS credentials from connection_properties

    VxFlex OS password is not stored in block_device_mapping table.
    Instead of this passwords are stored in separate file and are
    retrieved during each attach/detach operation.

    The stable/pike branch is in Extended Maintenance mode and is no
    longer released from. If you decide to apply this patch to your
    deployment, you must make a corresponding change to the os-brick
    library. You can find the os-brick patch for stable/pike here:
        https://review.opendev.org/#/c/733615

    Additionally, you must deploy a new configuration file on compute
    nodes, cinder nodes, and anywhere you would perform a volume
    attachment in your deployment. See the documentation change on
    this patch for details about the new config file.

    See OSSN-0086 for more information about this change:
        https://wiki.openstack.org/wiki/OSSN/OSSN-0086

    Change-Id: I975922b2ac951988e51743cd9f2f6f76be520840
    Closes-Bug: #1823200

Related fix proposed to branch: master
Review: https://review.opendev.org/746109

Reviewed: https://review.opendev.org/746109
Committed: https://git.openstack.org/cgit/openstack/os-brick/commit/?id=54504830828757e9d72e9440dde9cff33684a74d
Submitter: Zuul
Branch: master

commit 54504830828757e9d72e9440dde9cff33684a74d
Author: Gorka Eguileor <email address hidden>
Date: Thu Aug 13 13:13:02 2020 +0200

    ScaleIO: Connection info backward compatibility

    When we fixed bug 1823200 in Change-ID
    Iab54c515fe7be252df52b1a0503a251779805759 we made the ScaleIO connector
    incompatible with the old connection properties dictionary as it only
    supported the new 'config_group' and 'failed_over' parameters to get the
    password.

    This is a problem in any system that is upgraded and has attachments to
    the array, because the connection properties of those volumes will not
    contain the new fields and detaching them will result in error
    "KeyError: 'config_group'".

    This patch adds compatibility code to support the old connection
    properties format so we can detach those volumes.

    Related-Bug: #1823200
    Change-Id: I6f01a178616b74ed9a86876ca46e7e46eb360518

Related fix proposed to branch: stable/ussuri
Review: https://review.opendev.org/746572

Reviewed: https://review.opendev.org/746572
Committed: https://git.openstack.org/cgit/openstack/os-brick/commit/?id=31589a624fe8d2ebb56ccbd9c94a8dd559a7da89
Submitter: Zuul
Branch: stable/ussuri

commit 31589a624fe8d2ebb56ccbd9c94a8dd559a7da89
Author: Gorka Eguileor <email address hidden>
Date: Thu Aug 13 13:13:02 2020 +0200

    ScaleIO: Connection info backward compatibility

    When we fixed bug 1823200 in Change-ID
    Iab54c515fe7be252df52b1a0503a251779805759 we made the ScaleIO connector
    incompatible with the old connection properties dictionary as it only
    supported the new 'config_group' and 'failed_over' parameters to get the
    password.

    This is a problem in any system that is upgraded and has attachments to
    the array, because the connection properties of those volumes will not
    contain the new fields and detaching them will result in error
    "KeyError: 'config_group'".

    This patch adds compatibility code to support the old connection
    properties format so we can detach those volumes.

    Related-Bug: #1823200
    Change-Id: I6f01a178616b74ed9a86876ca46e7e46eb360518
    (cherry picked from commit 54504830828757e9d72e9440dde9cff33684a74d)

Related fix proposed to branch: stable/train
Review: https://review.opendev.org/746621

Reviewed: https://review.opendev.org/746621
Committed: https://git.openstack.org/cgit/openstack/os-brick/commit/?id=db95b001e2fe53a71ec0b881407ecdf7c3db32fc
Submitter: Zuul
Branch: stable/train

commit db95b001e2fe53a71ec0b881407ecdf7c3db32fc
Author: Gorka Eguileor <email address hidden>
Date: Thu Aug 13 13:13:02 2020 +0200

    ScaleIO: Connection info backward compatibility

    When we fixed bug 1823200 in Change-ID
    Iab54c515fe7be252df52b1a0503a251779805759 we made the ScaleIO connector
    incompatible with the old connection properties dictionary as it only
    supported the new 'config_group' and 'failed_over' parameters to get the
    password.

    This is a problem in any system that is upgraded and has attachments to
    the array, because the connection properties of those volumes will not
    contain the new fields and detaching them will result in error
    "KeyError: 'config_group'".

    This patch adds compatibility code to support the old connection
    properties format so we can detach those volumes.

    Related-Bug: #1823200
    Change-Id: I6f01a178616b74ed9a86876ca46e7e46eb360518
    (cherry picked from commit 54504830828757e9d72e9440dde9cff33684a74d)
    (cherry picked from commit 31589a624fe8d2ebb56ccbd9c94a8dd559a7da89)
    Conflicts:
            os_brick/initiator/connectors/scaleio.py

Related fix proposed to branch: stable/stein
Review: https://review.opendev.org/749833

Reviewed: https://review.opendev.org/749833
Committed: https://git.openstack.org/cgit/openstack/os-brick/commit/?id=173601116eb5e00274b10898b56b37dc42d685ac
Submitter: Zuul
Branch: stable/stein

commit 173601116eb5e00274b10898b56b37dc42d685ac
Author: Gorka Eguileor <email address hidden>
Date: Thu Aug 13 13:13:02 2020 +0200

    ScaleIO: Connection info backward compatibility

    When we fixed bug 1823200 in Change-ID
    Iab54c515fe7be252df52b1a0503a251779805759 we made the ScaleIO connector
    incompatible with the old connection properties dictionary as it only
    supported the new 'config_group' and 'failed_over' parameters to get the
    password.

    This is a problem in any system that is upgraded and has attachments to
    the array, because the connection properties of those volumes will not
    contain the new fields and detaching them will result in error
    "KeyError: 'config_group'".

    This patch adds compatibility code to support the old connection
    properties format so we can detach those volumes.

    This patch includes the release note from Change
    Ib98043358d51426ca650104ad59a7e09911ee8e9

    Related-Bug: #1823200
    Change-Id: I6f01a178616b74ed9a86876ca46e7e46eb360518
    (cherry picked from commit 54504830828757e9d72e9440dde9cff33684a74d)
    (cherry picked from commit 31589a624fe8d2ebb56ccbd9c94a8dd559a7da89)
    Conflicts:
            os_brick/initiator/connectors/scaleio.py
    (cherry picked from commit db95b001e2fe53a71ec0b881407ecdf7c3db32fc)

Related fix proposed to branch: stable/ussuri
Review: https://review.opendev.org/750050

Related fix proposed to branch: stable/train
Review: https://review.opendev.org/750051

Related fix proposed to branch: stable/stein
Review: https://review.opendev.org/750052

Reviewed: https://review.opendev.org/750050
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=7a20d32e85f0c1614a6687eb5142ef2e020f2fd4
Submitter: Zuul
Branch: stable/ussuri

commit 7a20d32e85f0c1614a6687eb5142ef2e020f2fd4
Author: Brian Rosmaita <email address hidden>
Date: Fri Sep 4 17:28:01 2020 -0400

    Require os-brick >= 3.0.3

    This version of brick contains a fix related to OSSN-0086, among
    other things.

    Change-Id: If0216831d616fc9d6c1907fc5ea6e796ab85ac39
    Related-bug: #1823200

Reviewed: https://review.opendev.org/750051
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=9e3e2ab25dac1e38d2344b0dd115204aa12db971
Submitter: Zuul
Branch: stable/train

commit 9e3e2ab25dac1e38d2344b0dd115204aa12db971
Author: Brian Rosmaita <email address hidden>
Date: Fri Sep 4 17:35:20 2020 -0400

    Require os-brick >= 2.10.5

    This version of brick contains a fix related to OSSN-0086, among
    other things.

    Depends-on: https://review.opendev.org/749905
    Change-Id: I2fb85babb34add6f705adc0e6a2b5b69fef3fbe7
    Related-bug: #1823200

Reviewed: https://review.opendev.org/750052
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=4cc9e7b5f101fb099d4840e91ee068880e5d29bd
Submitter: Zuul
Branch: stable/stein

commit 4cc9e7b5f101fb099d4840e91ee068880e5d29bd
Author: Brian Rosmaita <email address hidden>
Date: Fri Sep 4 17:41:54 2020 -0400

    Require os-brick >= 2.8.7

    This version of brick contains a fix related to OSSN-0086, among
    other things.

    Depends-on: https://review.opendev.org/750045
    Change-Id: I68130667e9c454b7f4e6d023401796226175c4bd
    Related-bug: #1823200

I want to add an addendum to comment #55. That roll-out plan worked fine, except that we should have used the same Change-Id on all the cinder patches, and same Change-Id on all the os-brick patches. This would have made it easier for people looking to see which branches contained the fix, because they would have been connected in the way backports usually are.

This issue was fixed in the openstack/cinder queens-eol release.

This issue was fixed in the openstack/os-brick queens-eol release.

This issue was fixed in the openstack/cinder rocky-eol release.

This issue was fixed in the openstack/os-brick rocky-eol release.