Seagate STX driver: Weak Cryptographic Algorithm (MD5) used

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

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

@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.

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.

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

@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.

@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