Seagate STX driver: Weak Cryptographic Algorithm (MD5) used

[Ataf Fazledin Ahamed]

## Overview
In the file [client.py](https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/stx/client.py#L124), a weak hashing algorithm (MD5) is used to hash the user password and get a session key. Since MD5 is deprecated and prone to hash collision, it's suggested that better algorithms (SHA256, SHA512, SHA3) are used as replacement.

One possible fix would be to use `sha3_256` or `sha3_512` algorithm from Python's `hashlib` library to replace the current `md5` algorithm.

### CLA Requirements:
This section is only relevant if your project requires contributors to sign a Contributor License Agreement (CLA) for external contributions.

All contributed commits are already automatically signed off.

The meaning of a signoff depends on the project, but it typically certifies that committer has the rights to submit this work under the same license and agrees to a Developer Certificate of Origin (see [https://developercertificate.org/](https://developercertificate.org/) for more information).
- [Git Commit Sign Off documentation](https://developercertificate.org/)

### Sponsorship and Support:
This work is done by the security researchers from OpenRefactory and is supported by the [Open Source Security Foundation (OpenSSF)](https://openssf.org/): [Project Alpha-Omega](https://alpha-omega.dev/). Alpha-Omega is a project partnering with open source software project maintainers to systematically find new, as-yet-undiscovered vulnerabilities in open source code - and get them fixed - to improve global software supply chain security.

The bug is found by running the iCR tool by [OpenRefactory, Inc.](https://openrefactory.com/) and then manually triaging the results.

[Jeremy Stanley (fungi)]

I've switched this report to a normal public bug and added a "won't fix" security advisory task to indicate that it's not something we'll be publishing an advisory about.

Note that the line referred to in the script is prefaced with a TODO comment pointing out pretty much exactly the same concern as was raised here.

The VMT is treating this as a class D report (security hardening opportunity) per our taxonomy: https://security.openstack.org/vmt-process.html#report-taxonomy

[Ataf Fazledin Ahamed (fazledynor)]

Hi Jeremy,

Thank you for replying.

I've noted that the line is prefaced with the TODO comment. I'm curious as why it wasn't updated, since the last commit was more than a year ago (March, 2022). If it's not a burden, can you kindly give me an explanation?

Thank you
Ataf

[Brian Rosmaita (brian-rosmaita)]

@Ataf This can't be fixed only on the cinder side. Tthe backend that's receiving the request has to know that it's getting something other than an md5 hexdigest and what exactly that thing is. So this change needs to be initiated by the STX driver team, which is apparently inactive.

[Ataf Fazledin Ahamed (fazledynor)]

Thanks @brian-rosmaita for the context. Is there anyone from the STX Driver team that I can contact? Or if you could direct me to the backend codebase (provided that it's public)- that would be very helpful.

[Chris M (pots)]

As Brian mentioned, the problem is with some older storage arrays that are supported by the driver but require MD5 hashes as part of their authentication handshake. These arrays reached end-of-support this year so they won't be getting firmware updates to fix this.

I would not want to unilaterally drop support for these older arrays from the driver--the weakness in MD5 is not a problem here--but I think it would be fine to publish a release note advising that they are deprecated and will be dropped in a future release to see if we get any feedback.

Brian, is there a formal policy to guide us here?

Chris

[Brian Rosmaita (brian-rosmaita)]

@pots: Chris, can you elaborate on "the weakness in MD5 is not a problem here"? That will help in assessing this. My understanding is that it's still OK to use MD5 as long as it's not being used in a "security context", and at first glance, passing a password obfuscated by MD5 seems to be a "security context".

I haven't looked closely at the driver code, but is it the case that the hexdigest in the URL is only there for backward compatibility, and the newer arrays are using a different authentication mechanism? Or is the plan that the firmware in newer arrays could be updated so that you use the credentials-in-the-url scheme, but with sha512 or something?

I don't think there's a formal policy yet ... there is a community goal that OpenStack be FIPS-compatible, so the main cinder code no longer uses MD5 in a security context, but since it's up to operators what backends and drivers they use, we have not required that all the drivers do the same (figuring that their customers will push them to do this).

The release note is a good idea, if you act fast we can get it into the Bobcat release notes.

[Chris M (pots)]

@brian-rosmaita:

What I meant is that we're not using the MD5 hash to verify the integrity of some other data, or making it available to a potential attacker--it's simply being used as a shared secret, and we rely on TLS to protect it from eavesdropping.

Newer arrays ignore the MD5 hash and look for HTTP Basic Auth headers instead, so you're correct that it's just there for backwards compatibility with the old arrays.

Since the affected arrays were sold by other companies, we'll reach out to them for their input.

Chris