Skip to main content

Log4j Vulnerability - Please Post All Questions Here


Show first post

344 replies

Forum|alt.badge.img

When running the affected servers report I receive “No Data Available” for features and hotfix installed boxes and “No records available” for the bottom table.  Is that the same as your note Note: If the resulting report shows No Data to Display, then there are no affected clients in this CommCell?  Since the verbiage doesn’t match completely, wanted to confirm without a doubt.

 

Disregard, I went back further in the comments and found this:

 


Forum|alt.badge.img+1
  • Bit
  • 7 replies
  • December 27, 2021

Our latest Tenable scan is showing the Content Index server file is vulnerable.  

 

c:\program files\commvault\simpana\ciserver\webapps\push.war 

Installed Version 1.2.15

 

I asked Support and they are saying its not, but per the scan it is showing up.  I need a resolution to prevent this from showing on scans if its not an issue.


Forum|alt.badge.img+2
  • Vaulter
  • 18 replies
  • December 27, 2021
nizmoz wrote:

Our latest Tenable scan is showing the Content Index server file is vulnerable.  

 

c:\program files\commvault\simpana\ciserver\webapps\push.war 

Installed Version 1.2.15

 

I asked Support and they are saying its not, but per the scan it is showing up.  I need a resolution to prevent this from showing on scans if its not an issue.

@nizmoz, are you using the Commvault reporting tool to validate status of the Commvault agents?


Forum|alt.badge.img+1
  • Bit
  • 7 replies
  • December 27, 2021
Scott A wrote:
nizmoz wrote:

Our latest Tenable scan is showing the Content Index server file is vulnerable.  

 

c:\program files\commvault\simpana\ciserver\webapps\push.war 

Installed Version 1.2.15

 

I asked Support and they are saying its not, but per the scan it is showing up.  I need a resolution to prevent this from showing on scans if its not an issue.

@nizmoz, are you using the Commvault reporting tool to validate status of the Commvault agents?

 

I have used it and it doesn’t show any.  But our Tenable Nessus scan doesn’t lie and saw the vulnerability.  CV support finally responded with this.

 

There is currently a project underway by CV Engineering to move all uses of log4j in the CV Software to 2.17.  I will let you know once we have a firm date on the release of this improvement.

 


Forum|alt.badge.img
  • Byte
  • 3 replies
  • December 27, 2021

The commvault report and sql query are not validated security tools. They just report that the update(s) installed on the client.

 

We get daily nessus reports of the CV infrastructure having a level 10 severity and have to explain to our customers that according to CV it is resolved.

 

CV will not get very far in saying that the platform is not affected unless the security vendors scan and show no vulnerabilities can be located.


Forum|alt.badge.img
  • Vaulter
  • 3 replies
  • December 28, 2021
Mike Struening wrote:
Scott Hall wrote:

I have applied the log4j-2.16 hotfixes to my Customer’s site on top of 11.24.25. The Log4j affected servers report shows that there is one client affected and also shows that the corrective fix is installed. However the Customer is reporting that their scans still show that vulnerable software is installed on the server --> /opt/commvault/Base32/DbJars/log4j-core-2.3.jar

  1. Are the hotfixes supposed to uninstall the older, vulnerable software?
  2. If not, can the Customer manually remove the file above themselves to clear the positive scan they are getting?

Thanks!

 

@Scott Hall , the old versions will be in the uninstall folder, though an upcoming Maintenance Release will clear everything out.

It’s recommended to leave it (it’s not active) and let the upcoming MR remove it.

@Mike Struening - Do you know which Maintenance Release is supposed to contain the hotfix to remove the old binaries from servers? My understanding was that it was 11.24.29, however we applied that yesterday but are still seeing older binaries in this location on the server: 

/opt/commvault/Base32/DbJars/log4j-core-2.3.jar

/opt/commvault/Base32/DbJars/log4j-api-2.3.jar

This is a linux server (non-HyperScale).

Thanks!


Forum|alt.badge.img+2
  • Vaulter
  • 18 replies
  • December 28, 2021
Scott Hall wrote:
Mike Struening wrote:
Scott Hall wrote:

I have applied the log4j-2.16 hotfixes to my Customer’s site on top of 11.24.25. The Log4j affected servers report shows that there is one client affected and also shows that the corrective fix is installed. However the Customer is reporting that their scans still show that vulnerable software is installed on the server --> /opt/commvault/Base32/DbJars/log4j-core-2.3.jar

  1. Are the hotfixes supposed to uninstall the older, vulnerable software?
  2. If not, can the Customer manually remove the file above themselves to clear the positive scan they are getting?

Thanks!

 

@Scott Hall , the old versions will be in the uninstall folder, though an upcoming Maintenance Release will clear everything out.

It’s recommended to leave it (it’s not active) and let the upcoming MR remove it.

@Mike Struening - Do you know which Maintenance Release is supposed to contain the hotfix to remove the old binaries from servers? My understanding was that it was 11.24.29, however we applied that yesterday but are still seeing older binaries in this location on the server: 

/opt/commvault/Base32/DbJars/log4j-core-2.3.jar

/opt/commvault/Base32/DbJars/log4j-api-2.3.jar

This is a linux server (non-HyperScale).

Thanks!

@Scott Hall, The December 19th release is the latest, and in your case, 11.24.29.  This MR should be removing the older binaries from the recovery path.  Are you using the Commvault report to scan the environment?


Forum|alt.badge.img
  • Vaulter
  • 3 replies
  • December 28, 2021
Scott A wrote:
Scott Hall wrote:
Mike Struening wrote:
Scott Hall wrote:

I have applied the log4j-2.16 hotfixes to my Customer’s site on top of 11.24.25. The Log4j affected servers report shows that there is one client affected and also shows that the corrective fix is installed. However the Customer is reporting that their scans still show that vulnerable software is installed on the server --> /opt/commvault/Base32/DbJars/log4j-core-2.3.jar

  1. Are the hotfixes supposed to uninstall the older, vulnerable software?
  2. If not, can the Customer manually remove the file above themselves to clear the positive scan they are getting?

Thanks!

 

@Scott Hall , the old versions will be in the uninstall folder, though an upcoming Maintenance Release will clear everything out.

It’s recommended to leave it (it’s not active) and let the upcoming MR remove it.

@Mike Struening - Do you know which Maintenance Release is supposed to contain the hotfix to remove the old binaries from servers? My understanding was that it was 11.24.29, however we applied that yesterday but are still seeing older binaries in this location on the server: 

/opt/commvault/Base32/DbJars/log4j-core-2.3.jar

/opt/commvault/Base32/DbJars/log4j-api-2.3.jar

This is a linux server (non-HyperScale).

Thanks!

@Scott Hall, The December 19th release is the latest, and in your case, 11.24.29.  This MR should be removing the older binaries from the recovery path.  Are you using the Commvault report to scan the environment?

@Scott A - When using the Commvault report, we see only the server in question and that it is “Fixed”. The Customer is performing their own scan and are seeing the same server with the older files mentioned above still present on the client. Due to this, they still consider the client “vulnerable”. I can also see these binaries in the location mentioned above via a client browse.

Where is the “recovery path” that we are removing the binaries from? If it is not the same path (/opt/commvault/Base32/DbJars), that would explain why they are not getting removed. If we can advise the Customer that it is fine to delete the files manually, that would also work for them but my understanding is that this would happen automatically with the MR install and that is not what we are seeing. 


Forum|alt.badge.img+2
  • Vaulter
  • 18 replies
  • December 28, 2021

@Scott Hall - If you are still seeing physical 2.3 binaries in the install path after upgrading, I would open a support case with Commvault to find out why the binaries are still present, ensure all the binaries were updated correctly and your customer is not at risk.


Forum|alt.badge.img+1
  • Bit
  • 7 replies
  • December 28, 2021

New vulnerability has been released today.  2.17 is now vulnerable.  

https://logging.apache.org/log4j/2.x/security.html


Forum|alt.badge.img+2
  • Vaulter
  • 18 replies
  • December 28, 2021
nizmoz wrote:

New vulnerability has been released today.  2.17 is now vulnerable.  

https://logging.apache.org/log4j/2.x/security.html

@nizmoz - Thank you for the detail.  I’ve been advised we are aware and looking into this and will be going to 2.17.1.  I’ve requested more detail from our teams and will update this thread when we are able.


Bart
Byte
Forum|alt.badge.img+13
  • Byte
  • 141 replies
  • December 29, 2021

and any impat based on CVE-2021-44832?


Forum|alt.badge.img+2
  • Vaulter
  • 18 replies
  • December 29, 2021
Bart wrote:

and any impat based on CVE-2021-44832?

@Bart - According to the national vulnerability database, this is resolved in 2.17.1.


Forum|alt.badge.img+1
  • Bit
  • 7 replies
  • December 29, 2021
Scott A wrote:
Bart wrote:

and any impat based on CVE-2021-44832?

@Bart - According to the national vulnerability database, this is resolved in 2.17.1.

When is CV going to use 2.17.1?


Forum|alt.badge.img+2
  • Vaulter
  • 18 replies
  • December 29, 2021
nizmoz wrote:
Scott A wrote:
Bart wrote:

and any impat based on CVE-2021-44832?

@Bart - According to the national vulnerability database, this is resolved in 2.17.1.

When is CV going to use 2.17.1?

@nizmoz - Our development teams are aware and will be using 2.17.1, but I do not have an ETA at this time.


Scott Moseman
Vaulter
Forum|alt.badge.img+18

This CVE pertains to the vulnerability causing the release of 2.17.1

https://documentation.commvault.com/v11/essential/146231_security_vulnerability_and_reporting.html

CVE-2021-44832: The Commvault software does not use the JdbcAppender module and, therefore, the vulnerability about remote code execution attack does not affect any Commvault products.

Thanks,
Scott
 


Forum|alt.badge.img+1
  • Bit
  • 7 replies
  • December 29, 2021
Scott Moseman wrote:

This CVE pertains to the vulnerability causing the release of 2.17.1

https://documentation.commvault.com/v11/essential/146231_security_vulnerability_and_reporting.html

CVE-2021-44832: The Commvault software does not use the JdbcAppender module and, therefore, the vulnerability about remote code execution attack does not affect any Commvault products.

Thanks,
Scott
 

Not sure how much I trust that, because our tenable scanner saw it was vulnerable on 1.2, above and they said it wasn’t and now they are working on fixing that issue.


Forum|alt.badge.img+11
  • Vaulter
  • 135 replies
  • December 29, 2021

Top post has now been updated regarding the latest vulnerabilities. 


Scott Moseman
Vaulter
Forum|alt.badge.img+18
nizmoz wrote:
Scott Moseman wrote:

CVE-2021-44832: The Commvault software does not use the JdbcAppender module and, therefore, the vulnerability about remote code execution attack does not affect any Commvault products.


Not sure how much I trust that, because our tenable scanner saw it was vulnerable on 1.2, above and they said it wasn’t and now they are working on fixing that issue.


I assume Tenable is simply scanning for the existence of the Log4J packages and not digging into the binaries of applications to determine if they’re using the exploited functions.

Thanks,
Scott
 


Forum|alt.badge.img+1
  • Bit
  • 7 replies
  • January 10, 2022

We are showing a new vulnerability with CommVault with Tenable.  See below.

It’s showing up on all our SQL servers, Media Agents and Exchange.

 


Forum|alt.badge.img+15

Hi @nizmoz 

Your screenshot is highlighting affected version 1.2.17 and CVE-2021-4104.

Please review the notes above in the original post which explain:


CVE-2021-4104: The Commvault software does not use the JMSAppender module and, therefore, the vulnerability about log4j 1.x versions does not affect any Commvault products.

and

Q:  I've noticed older 1.x versions of log4j being used in the platform.  Are these vulnerable? 

A:   We have some older instances in the installed component structure related to the older generation Log4J 1.x files which are not part of the current CVE Log4J 2.x vulnerability. We are doing further investigation on those conditions to determine a course of action.  

Thanks,

Stuart


Forum|alt.badge.img+1
  • Bit
  • 7 replies
  • January 10, 2022
Stuart Painter wrote:

Hi @nizmoz 

Your screenshot is highlighting affected version 1.2.17 and CVE-2021-4104.

Please review the notes above in the original post which explain:


CVE-2021-4104: The Commvault software does not use the JMSAppender module and, therefore, the vulnerability about log4j 1.x versions does not affect any Commvault products.

and

Q:  I've noticed older 1.x versions of log4j being used in the platform.  Are these vulnerable? 

A:   We have some older instances in the installed component structure related to the older generation Log4J 1.x files which are not part of the current CVE Log4J 2.x vulnerability. We are doing further investigation on those conditions to determine a course of action.  

Thanks,

Stuart

The files still exist, and our security team and management want them removed.  So can these safely be deleted if they are not being used?


Mike Struening
Vaulter
Forum|alt.badge.img+23

We recommend against removing anything manually.  It’s better to wait for development to conduct a full review and provide a plan for remediation.  We don’t want to end up breaking any portion of any operation.


Forum|alt.badge.img+10
  • Byte
  • 77 replies
  • January 11, 2022

I have been told by our security team as well about wanting them removed as we show a critical vuln for 1.2.16.  

CRITICAL: Plugin Name: Apache Log4j Unsupported Version Detection Plugin output - Path : C:\Program Files\Commvault\ContentStore\CustomReportsEngine\WEB-INF\lib\log4j-1.2.16.jar Installed version : 1.2.16

 

Hoping Commvault will release an update to correct the version of the 1.x jar.

 

Thanks

BC..

 

Thanks


Mike Struening
Vaulter
Forum|alt.badge.img+23

@bc1410 , dev is working on this now, though I can’t share a release date just yet.

Once it’s available, I’ll reply here and update the main post at the top.


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings