Skip to main content

Hi folks,

We are aware of a pair of new Zero-Day vulnerabilities tentatively listed under cve-2022-22963 and cve-2022-22965 also known as ‘spring4shell’.

We have an official page in our documentation for this situation located here. However, we can discuss late breaking updates or questions in this community thread.

 

Summary

Last updated May 5th, 2022, 12:28 AM EST

 

Commvault makes use of the Spring framework, however neither cve-2022-22963 or cve-2022-22965 apply to Commvault software or Metallic. Commvault does not not utilize the components for Spring MFC or Spring WebFlux, this means that we are not vulnerable to either exploit.

The spring framework is present in a few Commvault components - again, unaffected by the two stated vulnerabilities.

  1.  CVMessageQueue service (CVMessageQueue.exe), responsible for push notifications for jobs, events, and alerts. This service is deployed with the Web Console and Command Center package.

    Security scanners may find the location of affected spring binaries in Commvault\ContentStore\MessageQueue\lib\optional\

  2. SQL and Oracle agents 
    Security scanners may find DbArchiveEngine.jar which contains an older spring framework release.

Although we are not vulnerable to either exploit, updates will be made to update the Spring framework version to prevent being flagged by security scanners. This table of updates shows each maintenance release that removes binaries that can cause false positive alerts on security scanners.

Feature Release

Maintenance Release

11.26

11.26.23

11.25

11.25.32

11.24

11.24.48

11.23

11.23.59

11.20

11.20.103

SP16

SP16.153

 

Update log

 

Update May 5th, 2022, 12:28 AM EST

  • Table fully updated with all maintenance releases that update the required binaries

Update April 10th, 2022, 10:40 PM EST

  • Both updates are in test

Update April 4th, 2022, 7:30 PM EST

  • Reformatted post with summary
  • Added fix table with form IDs (will switch out to update / MR number once available)
  • Confirmed spring framework is applicable to SQL and Oracle agents (but not vulnerable)

Update April 4th, 2022, 6:40 PM EST

Some agents leverage the spring framework. Commvault leverages the framework in its .JAR form and does not leverage tomcat for these deployments and therefore is not vulnerable. 

Security scanners may find the location of affected spring binaries in:
/opt/commvault/Base64/DbJars

More to come...

 

Update April 3rd, 2022, 11:50 PM EST

We have an official page in our documentation for this situation located here.

To reiterate, Commvault is not affected by this vulnerability. As a precaution, we are upgrading the Message Queue application to the version recommended by Spring.io in our upcoming maintenance releases.


Update March 31, 2022, 10:45 PM EST

Early investigation from our engineering team shows that we do not utilize the components for Spring MFC or Spring WebFlux, meaning that we do not appear to be vulnerable to this recent exploit.

That being said, spring binaries are present as part of the JDK framework which is leveraged by our CVMessageQueue service (CVMessageQueue.exe), responsible for push notifications for jobs, events, and alerts. This service is deployed with the Web Console and Command Center package.

Security scanners may find the location of affected spring binaries in Commvault\ContentStore\MessageQueue\lib\optional\

 

Thanks, @Damian Andre

Please keep us updated. Our customers and security is very hard pushing for answers and the impact regarding this vulnerability.

 

 

Hi @Damian Andre 

please notice that we found some other Spring been usage in at least Cloud Apps and Oracle iDataagent.

>!]] ] found org/springframework/beans/CachedIntrospectionResults.class with hash 3559f9cda734a0516efb5a72fa6cea004ae50e96f0bf20f8dc1b7d90741f2ca1 (identified as version(s): 3.2.8.RELEASE, 3.2.9.RELEASE)
       └───────> found in /opt/commvault/Base64/DbJars/DbArchiveEngine.jar hash=afff5d46bc75ae5eeded3da8d15b3cd12d2a2e863dca0d84df88fa04c5c297cf  

 

can also please check those?

 

thnx,
Michel

 

 Do you know which version of the Spring files are part of the framework?

 

 Do you know which version of the Spring files are part of the framework?

 

  • Affected Spring Framework
    • 5.3.0 to 5.3.17
    • 5.2.0 to 5.2.19
    • Older versions (unsupported)

The current plan is to upgrade to the latest version of spring (5.3.18) which handles the reported vulnerability.

We’ll keep this thread up to date as we have progress to share.

Hi @Damian Andre 

please notice that we found some other Spring been usage in at least Cloud Apps and Oracle iDataagent.

p!]! ] found org/springframework/beans/CachedIntrospectionResults.class with hash 3559f9cda734a0516efb5a72fa6cea004ae50e96f0bf20f8dc1b7d90741f2ca1 (identified as version(s): 3.2.8.RELEASE, 3.2.9.RELEASE)
       └───────> found in /opt/commvault/Base64/DbJars/DbArchiveEngine.jar hash=afff5d46bc75ae5eeded3da8d15b3cd12d2a2e863dca0d84df88fa04c5c297cf  

 

can also please check those?

 

thnx,
Michel

 

According to the CVE, there’s a range of affected versions.  Once we upgrade to 5.3.18 and have an available patch, we will update here.

Thanks @Mike Struening good to hear that everything is been upgraded to latest version.

is there any ETA on the patch? 

Spring Release 3.2 found in Cloud Apps Component is out of Support since End of 2016. Why wasn’t that removed/replaced/upgraded in past 5 years?

Hi folks,

We are aware of a pair of new Zero-Day vulnerabilities tentatively listed under cve-2022-22963 and cve-2022-22965 also known as ‘spring4shell’.


Update March 31, 2022, 10:45 PM EST

….

We are currently evaluating how to best remediate this so that it does not appear on security scanners and we will provide a further update within the next 24 hours.

 

Hi @Damian Andre Do you have an update to “how to best remediate this”?

@Peder Sefland

https://documentation.commvault.com/v11/essential/146231_security_vulnerability_and_reporting.html#cv2022041-spring-framework

Resolution

“As stated in the Spring.io blog, if the application is deployed as a Spring Boot executable jar, which is the default jar, it is not vulnerable to the exploit. Commvault internally uses the Message Queue application, which includes the default Spring Boot executable jar that is not vulnerable to the exploit.

As a precaution, we are upgrading the Message Queue application to the version recommended by Spring.io in our upcoming maintenance releases.

Spring Release 3.2 found in Cloud Apps Component is out of Support since End of 2016. Why wasn’t that removed/replaced/upgraded in past 5 years?

@Stefan Vollrath , that’s definitely a valid question.  Changing any underlying library used is a pretty big undertaking, so it wasn’t taken underway without need.

With that said, we are undergoing a mass review of every library and older versions to work on upgrading them.

Hi folks,

We are aware of a pair of new Zero-Day vulnerabilities tentatively listed under cve-2022-22963 and cve-2022-22965 also known as ‘spring4shell’.


Update March 31, 2022, 10:45 PM EST

….

We are currently evaluating how to best remediate this so that it does not appear on security scanners and we will provide a further update within the next 24 hours.

 

Hi @Damian Andre Do you have an update to “how to best remediate this”?

Hey @Peder Sefland 

No immediate remediation necessary since we are not vulnerable, but there is a patching coming to update the framework. This has to go through the necessary test to ensure we don't accidently break anything downstream.

Is there a comprehensive List of Third Party Binaries and Libraries that Commvault uses and/or deploys  in which FeatureRelease and Versions included in what MaintenanceRelease? Ideally specifying too, with what Agent they are pushed?

https://documentation.commvault.com/11.24/expert/121377_third_party_applications_installed_by_commvault_installer.html only lists a fraction of what is used and couldn’t find anything else.

Maybe something in Store or Cloud I overlooked?

 

Is there an intention to update the Log4J Report to also include this new Vulnerability? Maybe morphing it to a generic Vulnerability Report on Cloud?

What is the Java version which Commvault uses ? It says that JDK 9 or higher might be vulnerable to the exploit.

Description

A Spring MVC or Spring WebFlux application running on JDK 9+ may be vulnerable to remote code execution (RCE) via data binding. The specific exploit requires the application to run on Tomcat as a WAR deployment. If the application is deployed as a Spring Boot executable jar, i.e. the default, it is not vulnerable to the exploit. However, the nature of the vulnerability is more general, and there may be other ways to exploit it.

These are the prerequisites for the exploit:

  • JDK 9 or higher
  • Apache Tomcat as the Servlet container
  • Packaged as WAR
  • spring-webmvc or spring-webflux dependency

Hi @Damian Andre@Mike Struening,

thanks for this confirmations that the Commvault software isn’t effected by this vulnerability. Several customers of us including our own Security department perform a lot of scanning on the systems and find this “Suspected”  Spring binaries on the customer systems. What is giving a lot of questions?
Can you please give more a detail ETA of the upgrade of those binaries?

thanks.

@Peder Sefland

https://documentation.commvault.com/v11/essential/146231_security_vulnerability_and_reporting.html#cv2022041-spring-framework

Resolution

“As stated in the Spring.io blog, if the application is deployed as a Spring Boot executable jar, which is the default jar, it is not vulnerable to the exploit. Commvault internally uses the Message Queue application, which includes the default Spring Boot executable jar that is not vulnerable to the exploit.

As a precaution, we are upgrading the Message Queue application to the version recommended by Spring.io in our upcoming maintenance releases.

Hi @Orazan is this including the spring binaries on the Cloud apps and DB agents?

What is the Java version which Commvault uses ? It says that JDK 9 or higher might be vulnerable to the exploit.

 

 

JDK 9 is just one of several requirements that has to be met - confirmed that we are not vulnerable to this due to it requiring a WAR deployment, amongst other criteria.

@Peder Sefland

https://documentation.commvault.com/v11/essential/146231_security_vulnerability_and_reporting.html#cv2022041-spring-framework

Resolution

“As stated in the Spring.io blog, if the application is deployed as a Spring Boot executable jar, which is the default jar, it is not vulnerable to the exploit. Commvault internally uses the Message Queue application, which includes the default Spring Boot executable jar that is not vulnerable to the exploit.

As a precaution, we are upgrading the Message Queue application to the version recommended by Spring.io in our upcoming maintenance releases.

Hi @Orazan is this including the spring binaries on the Cloud apps and DB agents?

Confirmed today that the spring framework is being used for some agents. I’m work to source an exact list on which ones. However, we’re leveraging it as a jar and there is no tomcat involved in the usage on the agent side, so Commvault is not vulnerable to cve-2022-22965 in this case.

 

Reply


Terms & ConditionsCookie settings