Log4j Vulnerability - Please Post All Questions Here



Show first post

344 replies

Userlevel 2
Badge +2

We just got this path reported on our Linux Media Agents

/opt/commvault/Base64/Huawei/FusionStorage/log4j-1.2.16.jar

I know that it’s probably not a problem (as we have nothing Huawei), but Tenable found it, so it’s on our reports and we’re going to want it addressed.

@Erik Soosalu Have you run the Commvault report against the client?  2.16 covers the vulnerabilities within our software.

Badge +2

We just got this path reported on our Linux Media Agents

/opt/commvault/Base64/Huawei/FusionStorage/log4j-1.2.16.jar

I know that it’s probably not a problem (as we have nothing Huawei), but Tenable found it, so it’s on our reports and we’re going to want it addressed.

Userlevel 6
Badge +15

@Scott A OK for /opt/commvault or custom path.

I personally have a different path for Commvault products, but what about the required 3rd party tools ?

I think it’s the question here.

 

Userlevel 2
Badge +2

@shane,  we use /opt/commvault. for our installation path.  That’s not to say the customer hasn’t changed the install path, but generally speaking our software is installed in /opt/commvault.   But either way, its a 1.x version and we’re not affected.

Badge +1

Link  is discussion - https://community.commvault.com/technical-blogs-and-articles-39/log4j-vulnerability-please-post-all-questions-here-1994

 

The report available via this link can only be run on a CS/CS basis. CV customer has 28 CS’s that all roll up to a Metrics server. my customer is asking for a report that can be uploaded to that metric server and run on all 28 CCID’s from there. Hopefully there is a solution for customers of this size.

Userlevel 3
Badge +8

@Shane are there any webservers or content indexing installed on that MA?

Nothing like that:

FS Core

MA

FS

VSA

Userlevel 2
Badge +2

@Shane are there any webservers or content indexing installed on that MA? Please be aware that log4j 1.x versions are not affected.

Userlevel 6
Badge +15

@Mohd Adnan 

Quoting @Onno van den Berg : 

Based on the hotfix in the MR I would say the gab between 23 / 29 is about +200 fixes and enhancements.  

And I would myself recommend to upgrade to the latest hotfix pack. BUT it your concern is only the log4j vulnerability, then it’s not necessary if you pushed the hotfixes to all of your clients.

@Shane 

I just deployed CVMA on a RHEL 7.9 today, but before your post.. So unfortunately I can’t tell you if it’s coming with CVMA packages or just the RHEL OS. 

Anyway I checked on another server without any Commvault product on it and found no /usr/share/java folder. I also checked on the linux sources, and it looks like whether it comes with apache/tomcat, or glibc runtimes.

==> Here a feedback from Vaulters would be appreciated. (though it’s not the right moment, we all agree on this)

 

And as already written before by some other people, thanks to all Vaulters a professionals that work on this topic and share as much as possible to address this issue. :thumbsup:  

Badge

Hi,

Log4j report showed no data and at before we have applied the below hotfix.

Do i still need to go on maintenance release 11.24.29 ?

 

11.24

11.24.23

11.24 Log4J-2.16 Fix

4552

4564

4551

4564

Userlevel 3
Badge +8

Hi all,

We have some Red Hat Enterprise Linux Server 7.9 Media Agents in an environment and the customer’s scans are picking up /usr/share/java/log4j as vulnerable (because it’s v1 (wait, hear me out)).

Is this something CV installs as part of the MA package? Does it need to be here?

Or is it something on the OS level (not our problem)?

Badge +2

Hello,

I have imported the latest version of “ Log4J affected servers “ report, when I run it does not show “ No Data to Display “ but the following, which is slightly different: 

 

 
Therefore, I am unsure if the report take into account all of our clients… I mean, I expect to see all clients listed in this report with their version and patch level instead of nothing…

Thank you in advance for your confirmation.
Regards.

R. 

Userlevel 7
Badge +19

@Mohit Chordia  I would strongly recommend to update all clients to the latest version. That way you are sure you are fully up-to-date and that there are no vulnerable version left in the Updates folder that can be picked up by scanners.

@0ber0n There is no new update for the report so the report most likely will not have the logic to take notice of the version that has the fixes embedded. The current version of the report only looks for the separate hotfixes. 

@Onno van den Berg Thank you . I have installed 2.16 hotfix on the clients which were highlighted in log4j server affected report. No action has been taken on CS , media agents and other clients . If it is not urgent and we are not vulnerable now , i would like to update my complete infrastructure to latest MR next year after the break. Let me know if this approach is ok ?

@Mohit Chordia that decision is all up to you! It should be possible from a technical point of view to run a higher MR on you clients than the one that is running on the CommServe and you are running a recent version so you should be fine. We however always keep the version chain inline because even though it should be possible the chance of running into unexpected issues is higher. Based on the hotfix in the MR I would say the gab between 23 / 29 is about +200 fixes and enhancements.  

Userlevel 3
Badge +11

@Mohit Chordia  I would strongly recommend to update all clients to the latest version. That way you are sure you are fully up-to-date and that there are no vulnerable version left in the Updates folder that can be picked up by scanners.

@0ber0n There is no new update for the report so the report most likely will not have the logic to take notice of the version that has the fixes embedded. The current version of the report only looks for the separate hotfixes. 

@Onno van den Berg Thank you . I have installed 2.16 hotfix on the clients which were highlighted in log4j server affected report. No action has been taken on CS , media agents and other clients . If it is not urgent and we are not vulnerable now , i would like to update my complete infrastructure to latest MR next year after the break. Let me know if this approach is ok ?

Userlevel 3
Badge +11

@Mohit Chordia, It would be better to maintain consistent versioning across your environment as any mis-match in versions between Commserve, Media Agents and Clients may cause inconsistencies in behaviour.

 

Thank you . I have installed 2.16 hotfix on the clients which were highlighted in log4j server affected report. No action has been taken on CS , media agents and other clients . If it is not urgent and we are not vulnerable now , i would like to update my complete infrastructure to latest MR next year after the break. Let me know if this approach is ok ?

 

Userlevel 5
Badge +11

Hi @Mohit Chordia 

 

If you have already updated your impacted SQL servers with the Log4j 2.16 hotfixes, then there is no need to install the latest Maintenance Release at this point. It contains the same fixes, just rolled up for easier installation. This Maintenance Release is ideal for those who have yet to deploy the loose hotfixes so that everything is now rolled up into one package.

 

Thank you

Thank you . I have installed 2.16 hotfix on the clients which were highlighted in log4j server affected report. No action has been taken on CS , media agents and other clients . If it is not urgent and we are not vulnerable , i would like to update my complete infrastructure to latest MR next year after the break.

Hi @Mohit Chordia 

 

That sounds like a plan :)

Userlevel 3
Badge +11

Hi @Mohit Chordia 

 

If you have already updated your impacted SQL servers with the Log4j 2.16 hotfixes, then there is no need to install the latest Maintenance Release at this point. It contains the same fixes, just rolled up for easier installation. This Maintenance Release is ideal for those who have yet to deploy the loose hotfixes so that everything is now rolled up into one package.

 

Thank you

Thank you . I have installed 2.16 hotfix on the clients which were highlighted in log4j server affected report. No action has been taken on CS , media agents and other clients . If it is not urgent and we are not vulnerable , i would like to update my complete infrastructure to latest MR next year after the break.

Userlevel 3
Badge +8

Hi @Shane 

 

Commvault does not use JMSAppender so technically is not impacted by this latest Log4j 1.x vulnerability. Commvault however are working on updating all Log4j 1.x binaries in the near future. 

Nice, thanks.

Userlevel 5
Badge +11

Hi @Shane 

 

Commvault does not use JMSAppender so technically is not impacted by this latest Log4j 1.x vulnerability. Commvault however are working on updating all Log4j 1.x binaries in the near future. 

Userlevel 3
Badge +8

Hi @Nishika 

 

In regards to your other scan results, these are Log4j 1.x files. These are not impacted by the critical 0-day Log4j vulnerability which only impacts v2.x prior to 2.15. Commvault will address Log4j 1.x files in the near future but in the interim, please do not delete these as it may impact your backups. 

Hi, is there an article stating this as an official stance?

My customers are getting quite tense.

 

Hi @Shane 

 

For example here: https://nvd.nist.gov/vuln/detail/CVE-2021-44228 and https://www.cisa.gov/uscert/ncas/current-activity/2021/12/10/apache-releases-log4j-version-2150-address-critical-rce

It is mentioned only 2.x versions impacted

Apache Log4j2 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints

 

Thank you

Thank you for this.

Is there an official response to this: https://www.tenable.com/cve/CVE-2021-4104

JMSAppender in Log4j 1.2 is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration. The attacker can provide TopicBindingName and TopicConnectionFactoryBindingName configurations causing JMSAppender to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-44228. Note this issue only affects Log4j 1.2 when specifically configured to use JMSAppender, which is not the default. Apache Log4j 1.2 reached end of life in August 2015. Users should upgrade to Log4j 2 as it addresses numerous other issues from the previous versions.

Userlevel 5
Badge +11

Hi @Nishika 

 

In regards to your other scan results, these are Log4j 1.x files. These are not impacted by the critical 0-day Log4j vulnerability which only impacts v2.x prior to 2.15. Commvault will address Log4j 1.x files in the near future but in the interim, please do not delete these as it may impact your backups. 

Hi, is there an article stating this as an official stance?

My customers are getting quite tense.

 

Hi @Shane 

 

For example here: https://nvd.nist.gov/vuln/detail/CVE-2021-44228 and https://www.cisa.gov/uscert/ncas/current-activity/2021/12/10/apache-releases-log4j-version-2150-address-critical-rce

It is mentioned only 2.x versions impacted

Apache Log4j2 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints

 

Thank you

Userlevel 3
Badge +8

Hi @Nishika 

 

In regards to your other scan results, these are Log4j 1.x files. These are not impacted by the critical 0-day Log4j vulnerability which only impacts v2.x prior to 2.15. Commvault will address Log4j 1.x files in the near future but in the interim, please do not delete these as it may impact your backups. 

Hi, is there an article stating this as an official stance?

My customers are getting quite tense.

Userlevel 5
Badge +11


 The Commvault affected client report does not list the client;  version installed on the client SP22-Hot-Fix 3910, SP22-Hot-Fix 3911, SP22-Hot-Fix 3911 it was installed on 14th Dec
 SP is 22.50; however when a customer runs the utility it is showing the following files : 

 

 

We have only installed the hotfixes , SP22-Hot-Fix 3911 which was done on Dec 14th as per update log however cant see a reference for hotfix 39120
 

 

Hi @Theseeker 

If the report is not listing your client at all, then the client did not need the patch.

 

Regarding your scan results, can confirm DbArchiveEngine.jar is incorrectly being picked up by scanners. You can see that the scanner is also unable to determine the version of Log4j used and thus marking as “potentially vulnerable” where in fact this binary has already been patched if you have either the hotfix installed or the latest Maintenance Release.

 

Thank you

Userlevel 2
Badge +8


 The Commvault affected client report does not list the client;  version installed on the client SP22-Hot-Fix 3910, SP22-Hot-Fix 3911, SP22-Hot-Fix 3911 it was installed on 14th Dec
 SP is 22.50; however when a customer runs the utility it is showing the following files : 

 

 

We have only installed the hotfixes , SP22-Hot-Fix 3911 which was done on Dec 14th as per update log however cant see a reference for hotfix 39120
 

 

Userlevel 5
Badge +11

Hi @Nishika ,

 

An updated version of the report has been released to address the issues with latest MR pack. Download link is the same as sticky post at top, and copied below:

https://cloud.commvault.com/webconsole/softwarestore/store.do#!/135/663/21789

 

Note that version is now 1.1.2.3

 

Thank you

Userlevel 5
Badge +11

Hi @Nishika 

 

We are aware of this reporting issue and working on updating this. Suspect it is due to the latest Maintenance Release that report is incorrectly showing “No” under corrective fix column.

 

In regards to your other scan results, these are Log4j 1.x files. These are not impacted by the critical 0-day Log4j vulnerability which only impacts v2.x prior to 2.15. Commvault will address Log4j 1.x files in the near future but in the interim, please do not delete these as it may impact your backups. 

Reply