Skip to main content

Log4j Vulnerability - Please Post All Questions Here


Show first post

344 replies

Forum|alt.badge.img+8
  • Commvault Certified Expert
  • 74 replies
  • December 22, 2021
Jordan wrote:
Shane wrote:
Jordan wrote:

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.


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

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. 


Forum|alt.badge.img+8
  • Commvault Certified Expert
  • 74 replies
  • December 22, 2021
Jordan wrote:

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.


Mohit Chordia
Byte
Forum|alt.badge.img+11
Jordan wrote:

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.


Forum|alt.badge.img+11
  • Vaulter
  • 135 replies
  • December 22, 2021
Mohit Chordia wrote:
Jordan wrote:

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 :)


Mohit Chordia
Byte
Forum|alt.badge.img+11
Scott A wrote:

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

 


Mohit Chordia
Byte
Forum|alt.badge.img+11
Onno van den Berg wrote:

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


Onno van den Berg
Commvault Certified Expert
Forum|alt.badge.img+19
  • Commvault Certified Expert
  • 1227 replies
  • December 22, 2021
Mohit Chordia wrote:
Onno van den Berg wrote:

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


Forum|alt.badge.img+4
  • Byte
  • 12 replies
  • December 22, 2021

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. 


Forum|alt.badge.img+8
  • Commvault Certified Expert
  • 74 replies
  • December 22, 2021

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)?


Mohd Adnan
Bit
Forum|alt.badge.img
  • Bit
  • 1 reply
  • December 22, 2021

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


Forum|alt.badge.img+15
  • Byte
  • 386 replies
  • December 22, 2021

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


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

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


Forum|alt.badge.img+8
  • Commvault Certified Expert
  • 74 replies
  • December 22, 2021
Scott A wrote:

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

Nothing like that:

FS Core

MA

FS

VSA


Stephen
Vaulter
Forum|alt.badge.img+1
  • Vaulter
  • 2 replies
  • December 22, 2021

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.


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

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


Forum|alt.badge.img+15
  • Byte
  • 386 replies
  • December 22, 2021

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

 


Forum|alt.badge.img+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.


Forum|alt.badge.img+2
  • Vaulter
  • 18 replies
  • December 22, 2021
Erik Soosalu wrote:

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.


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

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

 

@Laurent Which 3rd party tools are you referring to?


Forum|alt.badge.img+2
Scott A wrote:
Erik Soosalu wrote:

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.

 

We’re fully patched at 11.23.42 and the report shows nothing.

I know this is a log4j 1.x issue so not the highest priority.   This was just a new one that Tenable is starting to show in our environment and until it is either updated or removed we’re going to keep getting flak for it.

 

 

 


Forum|alt.badge.img+2
  • Vaulter
  • 18 replies
  • December 22, 2021
Erik Soosalu wrote:
Scott A wrote:
Erik Soosalu wrote:

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.

 

We’re fully patched at 11.23.42 and the report shows nothing.

I know this is a log4j 1.x issue so not the highest priority.   This was just a new one that Tenable is starting to show in our environment and until it is either updated or removed we’re going to keep getting flak for it.

 

 

 

@Erik Soosalu.  Thanks Erik, that is good to hear.  I know 1.x is not affected by this vulnerability and is listed as end of life after 2015.  Our updates are targeting the CVSS 10 vulnerability affected in the 2.x versions, although we are investigating upgrade paths for 1.x that will be addressed separately.  If possible, users should upgrade to Log4J 2.x as you have already done.


Forum|alt.badge.img+1
  • Bit
  • 3 replies
  • December 22, 2021
RC23 wrote:

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. 

Did you get an answer on your question?  I’m seeing the same screens when I run the report in my environment and I’ve applied the Hotfix to a few servers that I’d expect to show up in the list.


Forum|alt.badge.img+8
  • Vaulter
  • 53 replies
  • December 22, 2021
Nick734810 wrote:
RC23 wrote:

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. 

Did you get an answer on your question?  I’m seeing the same screens when I run the report in my environment and I’ve applied the Hotfix to a few servers that I’d expect to show up in the list.

Did the servers have table level restore, archive, or data masking enabled?  Its only going to show the high risk applications with those features enabled.  If you have SQL, Oracle, or Cloud app servers, without those advanced features - log4j 2.x is not in use, so they are lower risk - although we generally recommend upgrading anyway.


Forum|alt.badge.img+1
  • Bit
  • 3 replies
  • December 22, 2021
DMCVault wrote:
Nick734810 wrote:
RC23 wrote:

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. 

Did you get an answer on your question?  I’m seeing the same screens when I run the report in my environment and I’ve applied the Hotfix to a few servers that I’d expect to show up in the list.

Did the servers have table level restore, archive, or data masking enabled?  Its only going to show the high risk applications with those features enabled.  If you have SQL, Oracle, or Cloud app servers, without those advanced features - log4j 2.x is not in use, so they are lower risk - although we generally recommend upgrading anyway.

No it doesn’t look like they had those features enabled.  Thanks for the information.


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