Log4j Vulnerability - Please Post All Questions Here


Userlevel 7
Badge +23

Summary
 

The following thread describes the potential exposure to the Apache Log4j vulnerability and steps to update Commvault software.

It has been confirmed that a small subset of Commvault agents are impacted. 

 

Update as of 1st February: Maintenance Release to bring Log4j version to 2.17.1 across Commvault software platform has been released. This release includes the upgrade of components that previously used Log4j 1.x. 

 

Update as of 20th December: Maintenance Release including relevant hotfixes now available for Commvault software, see section “Maintenance Releases”. Please note customers who have already applied hotfixes for Log4j 2.16, do not need to install.

For customers with Commvault Hyperscale X and Distributed storage, please see section new Community article here: 

 

Apache Log4j information

  • CVE-2021-44228: Apache Log4j2 JNDI features do not protect against attacker controlled LDAP and other JNDI related endpoints. From log4j 2.15.0, this behavior has been disabled by default
  • CVE-2021-45046: Apache Log4j 2.15.0 was incomplete in certain non-default configurations. Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default
  • CVE-2021-45105: Apache Log4j2 did not protect from uncontrolled recursion from self-referential lookups. This allows an attacker with control over Thread Context Map data to cause a denial of service when a crafted string is interpreted. 
  • CVE-2021-4104: JMSAppender in Log4j 1.2 is vulnerable to deserialization of untrusted data.

  • CVE-2021-44832: Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) attack where an attacker with permission to modify the logging configuration file can construct a malicious configuration using a JDBC Appender with a data source referencing a JNDI URI which can execute remote code.

Note: Log4j version 1.x is NOT affected.

There’s a great blog article that covers the potential impact.

 

Updates:

CVE-2021-45105: Commvault can confirm that the affected Log4j2 function is NOT leveraged by Commvault software and thus there is no immediate need to update Commvault to use Log4j 2.17. 

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.

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.

 

Identifying and Updating Commvault

 

Exposure:

Note: check FAQ at the bottom of this post for specific version questions.

The exposure impacts the below Commvault product features:

Cloud Apps package
Oracle agent - Database archiving, data masking, and logical dump backup
Microsoft SQL Server agent - Database archiving, data masking, and table level restore

Commvault Distributed Storage

Commvault Hyperscale X

 

Identifying affected servers using the Commvault Log4j report

 

Please use the below direct link to download the Commvault Log4J Affected Servers report then follow step 4 to import and run

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

 

Alternatively, follow steps 1-3 to manually download the Commvault report:

  1. Log into cloud.commvault.com and click the Software Store tile icon 
  2. Search the Store for Log4j and click the Download button for the “Log4J affected servers” report 
  3. Log into Command Center and navigate to Reports
  4. At the top right of the Reports page, click Actions and Import report. Proceed to select the downloaded report file to import into Command Center. 
  5. Now you can run the report.

This report will show you any servers with Cloud Apps, SQL Server, and Oracle Database packages installed that may be affected by Log4j vulnerability.
Note: If the resulting report shows No Data to Display, then there are no affected clients in this CommCell

The easiest course of action is to upgrade all servers listed in this report (Oracle, Cloud Apps, and SQL) – that would be the recommendation. However, at a minimum, servers with Database Archiving, Data Masking, or Extent based backups (SQL table level restore) features enabled should have highest priority as the vulnerable log4j package is actively used, while otherwise the packages are dormant.

 

Maintenance Releases

 

The table below outlines the specific Maintenance Releases that will both address Log4j 2.x vulnerabilities as well as update Log4j 1.x components to 2.17.1 (the latest release of Log4j)

Note: If the previous Log4j 2.16 hotfixes has already been applied, then this latest Maintenance Release is optional 

Feature Release

Maintenance Release

11.26

11.26.21

11.25

11.25.32

11.24

11.24.48

11.23

11.23.47

11.20

11.20.90

SP16

SP16.153

 

How to deploy Maintenance Release:

 

  1. First perform a disaster recovery backup using steps HERE .
  2. OPTIONAL: create a server group containing all the affected servers using instructions HERE.  This can make it easier to select servers for the upgrade process.
  3. Go to documentation to find the list of updates: https://documentation.commvault.com/11.24/essential/146231_security_vulnerability_and_reporting.html
  4. Download the maintenance pack for the version the CommServe is running on. 

    If you do not know the CommServe version, in Command Center search for About and click the About search result to bring up the version popup. 
  5. Extract the Maintenance Pack
  6. Follow instructions HERE to copy the software packages to the cache using Command Center.  
  7. Proceed to Install updates following instructions HERE .  You can update only the affected clients to avoid the CommServe services stopping, however it is recommended to update the CommServe and all affected servers as shown on the report for completeness.
  8. Once completed re-rerun the report to show that the servers have the appropriate fixes

Note: For instructions on how to apply Log4j 2.16 hotfixes on older Maintenance Release, please see FAQ

 

See Commvault Online Documentation for additional information:

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

 

HyperScale X and CDS (Hedvig)

 

For all detailed information on how to update HyperScale X and Commvault Distributed Storage (CDS) to address Log4j vulnerabilities, please see article here:

 

 

Log4j FAQ 

 

Q:   There is a new vulnerability in 2.15 is Commvault addressing this? 

A:   The LOG4J 2.15 version (GA Dec. 06, 2021) disabled the essential exploit functions by default was released last week on Dec 6, 2021. This was considered the market-acceptable, non-vulnerable upgrade package up to today.  

 The Apache organization released a new version, 2.16, on Monday, Dec.13, 2021, which physically removes the vulnerable functions. 

 This evening, the security groups issued a new vulnerability CVE-2021-45046 targeting concerns with the 2.15 version and recommending the shift to 2.16.   

  This significant change affects all client remediation methods, requiring an upgrade to version 2.16.  Log4j 2.16 hotfixes have now been released, please see table above

 

Q: When will new hotfixes be available for 2.16 log4j? 

A: Log4j 2.16 hotfixes have now been released, please see table above

 

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.  

We do plan to remove all 1.x references in the Feb 1st maintenance release to prevent “false alarms”.  That version is not vulnerable to the current respective CVEs, but it would clear up the scanning concerns.

 

Q:  I noticed HyperScale 1.5 is using end of life versions of Log4j.  Is this being resolved? 

A:  The 1.x versions of log4j bundled with HyperScale 1.5 are maintained and supported by Redhat.  These versions are not affected by this CVE. 

 

Q: Are older versions like v10 and v9 affected?

A: These versions are not affected

 

Q: Why are some updates showing skipped during Copy to Cache?

A: These are updates for Operating Systems your CommCell does not have.  It’s more informational than error related.

 

Q: Why does the report show No Records Available or No Items to Display?

A: This means there are no affected clients in this CommCell

 

Q: What order should I apply the updates?

A: The Maintenance Release needs to be installed first, then the Hotfix Pack.  The best option is to use Copy to Cache, followed by pushing the updates out from the GUI as per the instructions.  This will ensure everything is applied as needed in the correct order.

 

Q: Can I remove versions manually?

A: No, removing anything manually will potentially cause features to not work properly.  Use the Maintenance Releases and Hotfix packs to remediate.

 

Q: Is Anti-virus a concern?

A: It is possible that an AV service may lock the affected files out of concern and cause features to not work properly.  Use the Maintenance Releases and Hotfix packs to remediate.

 

Q: How do I download Maintenance Release using CommCell Console?

A: Please follow Commvault Online Documentation steps below

https://documentation.commvault.com/11.25/expert/2705_downloading_commvault_software_using_commcell_console.html

 

Q: Is Metallic vulnerable to the vulnerability?

A: We have found that the Log4j vulnerability has no impact on Metallic or the security and privacy of your data backups. Metallic does not use the impacted libraries as per the Apache Log4j advisory.

We will continue to proactively monitor and provide any further updates, while customers with questions can reach out to Metallic.io/support.

 

Q: Log4j scanner is still picking up DbArchiveEngine.jar as potentially vulnerable?

A: Some Log4j scanners are actually incorrectly picking up DbArchiveEngine.jar as potentially vulnerable when in fact it is already patched. This is because the scanner was unable to determine the version of Log4j used and ending up marking it as “potentially vulnerable”. Please note that if you have patched Commvault clients with either the 2.16 hotfix or the latest Maintenance Release, then this DbArchiveEngine.jar binary is also patched and will not have the Log4j 0-day vulnerability. 

 

Q: I have updated to latest Maintenance Release but Log4j Affected Servers report is still showing my clients as not fixed?

A: There has been a new Log4j Affected Servers report released on December 22nd that has updated the checks to correctly report fixed for clients on the latest Maintenance Release. This new report is version 1.1.2.3 whereas the previous report is 1.1.2.2.

 

Q: How do I apply the Log4j hotfixes if I am already on the older minimum required Maintenance Release?

A: Please follow below steps:

  1. Ensure the Commserve and affected clients are on the minimum required Maintenance Release pack. 
    1. If not, please download and install using the CommCell Console 
    2. Alternatively, you may download the minimum required Maintenance Release from the links in the table below
  2. Download the Log4J-Fix pack for your version
  3. Unzip the contents of the download
  4. Run Copy To Cache and point to the folder created by the unzip to add the new updates to your software cache
  5. Push out updates to the clients
  6. Verify client status by checking the Log4j Affected Servers report or Client Details report or viewing the client properties

Log4j 2.16 fixes (CVE-2021-44228, CVE-2021-45046)

Feature Release

Minimum Required
Maintenance Release

Update Link (includes 2.16 fix)

Installed Windows
Updates

Installed
Unix Updates

11.26

11.26.2

11.26 Log4J-2.16 Fix

1755

1755

11.25

11.25.9

11.25 Log4J-2.16 Fix

2763

2779

2763

2779

11.24

11.24.23

11.24 Log4J-2.16 Fix

4552

4564

4551

4564

11.23

11.23.37

11.23 Log4J-2.16 Fix

4160

4178

4161

4178

11.22

11.22.50

11.22 Log4J-2.16 Fix

3911

3920

3912

3920

11.21

11.21.66

11.21 Log4J-2.16 Fix

3587

3599

3588

3599

11.20

11.20.77

11.20 Log4J-2.16 Fix

4562

4574

4561

4574

SP16

SP16.128

SP16 Log4J-2.16 Fix

2943

2946

2942

2946


344 replies

Badge +3

Our Commserve and Media agent were running on 11.20.77. I have copied hotfix to cache and I was able to push udpates to Media agents and clients and successfully updated them. However, update job just gets stuck and doesn’t install on Commserve. 

 

Updateinfo log attached.

 

I have also tried to run v11SP20_Available_HotFix4562_WinX64 manually. This execution also ends saying waiting for dedup process to exit and all commvault services go to disabled state. I have to set them all to automatic and restart manually. 

Userlevel 5
Badge +11

Hi @ameersyed 

 

Please raise a support incident to specifically review your CS and why the updates are not installing.

 

Something appears to be stuck based on your log snippet.

 

Thank you

Badge

Hello there,

 

I see that Maintenance Release 82 is available. So my question is if installing Maintenance Release 82 for version 11.20 would suffice this vulnerability ?

 

Thank you

Userlevel 7
Badge +15

Hi @Krishan Bhatt 

There are 2 steps to apply this fix:

  1. Bring your environment up to the minimum MR level for your version
  2. Download and install the appropriate Log4j fixes for your version

As you are running 11.20.82, that’s step 1 achieved, but you still need to download and apply the log4j fixes for 11.20.

Thanks,

Stuart

Hi,

Please would you be able to clear up a couple of questions for me please?

  1. We are running 11.20.82 and when clicking on the link provided and downloading the 11.20 Log4J Fix files provided, within that zipped folder it lists different files for different operating systems. Can you confirm which we should be using as there appears to be two different .exe files for two separate Hotfixes (HotFix4562 and HotFix4563)
    1. In regards to installing this .exe file remotely via the CommCell console it says in the original post of this thread that to install the “Hotfix” we should be able to add it to the cache and remotely update each agent. Can you clarify which you are referring to at this point? Is this to install the “Maintenance Release” or the “Log4JFix”. If this is for the Log4JFix then please could you confirm that this does work as we have had issues attempting to add the file to the cache.
Userlevel 7
Badge +15

Hi @James_Goodison 

You will need to apply both the minimum or higher MR level for your version plus all the hotfixes provided.

The hotfixes provided cover all affected agents for different client OSes, you need to import all the hotfixes to the cache and on installation, on the required hotfixes are provided.

If you are having trouble importing the hotfixes to the cache, please try running a copy software job on the folder containing the still zipped Log4J-Updates.zip.

Thanks,

Stuart

Badge

Hi @James_Goodison 

You will need to apply both the minimum or higher MR level for your version plus all the hotfixes provided.

The hotfixes provided cover all affected agents for different client OSes, you need to import all the hotfixes to the cache and on installation, on the required hotfixes are provided.

If you are having trouble importing the hotfixes to the cache, please try running a copy software job on the folder containing the still zipped Log4J-Updates.zip.

Thanks,

Stuart

Hi Stuart, 
Apologies, please can you clarify your statement? 

I’ve installed the 11.20.82 MR, do I now need to install every hotfix in the folder to every agent? (Hotfix4562_Win32 and X64 AND Hotfix4563_Win32 and X64?)

Can these be installed remotely via copy software job etc or do I need to install these manually on each agent? Agents only use Windows SQL Server. 

 

Thanks in advance. 

Hi @James_Goodison 

You will need to apply both the minimum or higher MR level for your version plus all the hotfixes provided.

The hotfixes provided cover all affected agents for different client OSes, you need to import all the hotfixes to the cache and on installation, on the required hotfixes are provided.

If you are having trouble importing the hotfixes to the cache, please try running a copy software job on the folder containing the still zipped Log4J-Updates.zip.

Thanks,

Stuart

In our environment we are only managing x64 Windows Operating System servers running SQL Server. Are you saying that in order to plug this vulnerability we need to install the following 4 updates from the Log4J-Updates.zip to each server?

v11SP20_Available_HotFix4562_Win32.exe
v11SP20_Available_HotFix4562_WinX64.exe
v11SP20_Available_HotFix4563_Win32.exe
v11SP20_Available_HotFix4563_WinX64.exe

Also are you saying that we can add these 4 updates to the CommVault software Cache and remotely push these out?

Badge

Hi @Krishan Bhatt 

There are 2 steps to apply this fix:

  1. Bring your environment up to the minimum MR level for your version
  2. Download and install the appropriate Log4j fixes for your version

As you are running 11.20.82, that’s step 1 achieved, but you still need to download and apply the log4j fixes for 11.20.

Thanks,

Stuart

I have installed the hotfix for 11.20.77 however the CS and MA servers are showing only SP20-HotFix-4562.

 

Is it OK that way or the servers are suppose to show all hotfixes viz HotFix4561 HotFix4562 HotFix4563

 

Thank you

Userlevel 7
Badge +15

Hi @EPick 

Yes, it’s a 2 stage task:

  1. Update to the minimum level MR for your version.
  2. Install all the hotfixes provided for affected clients

If you deploy hotfixes to clients that aren’t affected, there’s no issues there, the installer will simply exit with a message similar to “there are no updates applicable for this system” as not all clients/agents are affected by log4l vulnerability.

Likewise, the hotfixes target separate packages with different hotfixes for Cloud Apps, Oracle and SQL, so not all hotfixes apply to all clients.

And  yes, you can run a copy software job to import the hotfixes to the software cache and deploy centrally from the Commserve.

Thanks,

Stuart

Userlevel 7
Badge +15

Hi @James_Goodison 

You only need to install the hotfixes for the versions you have installed, if you only have x64 bit clients, you will only need to deploy the 64 bit hotfixes.

When you import these hotfixes into the software cache and then run an install updates job, the Commserve and software cache is intelligent to only provide hotfixes for the client installation version and the packages installed on that client.

 

@Krishan Bhatt 

Commserve and MA are not affected by the log4j vulnerability, but they may have packages installed for corresponding hotfixes, e.g. FileSystemCore agent will be found on every client in the Commcell.

You will only see hotfixes shown in client properties if that client has a package installed with a corresponding hotfix.

For example, where we are providing a hotfix for Oracle agent, if you attempt to install this on the Commserve, it will tell you no updates applicable for this client and likewise the Oracle hotfix will not be shown on Commserve client properties.

 

Thanks,

Stuart

Hi @Stuart Painter , 

Is there a way to see in the CommServe gui which hotfixes are already applied to Clients? Also I have manually installed the 2 x64 patches to one of our test servers and now it states the agent is “ahead of cache” is this what you would expect?

 

Badge

hello,

i did all the recemented steps the you wrote

  1. Unzip the contents of the download
  2. Run Copy To Cache to add the new updates to your software cache
  3. Push out updates to the clients

How do I make sure the update has worked and I am no longer vulnerable?
Is there a way to identify it? Does the agent version change?
Just to note, we only have SQL agents

     

Userlevel 7
Badge +15

Hi @James_Goodison 

If you have manually installed MR or hotfixes manually on a client before importing to the cache, then yes, these clients would be classified as “ahead of cache”.

Importing MR and hotfixes into the cache will bring these into line.

You can check client properties in the Commcell console, the client lines as you have in your screenshot show the MR version, but won’t list specific hotfixes installed. Client properties for each client will show hotfixes installed and against which package they apply.

Thanks,

Stuart

Badge +1

We have successfully installed the Hotfix for our 11.20.77 environment. In the Java Console the applied hotfixes are shown as expected:

But when we perform a scan for vulnerable log4j files, by using the command line utility form lunasec (https://www.lunasec.io/docs/blog/log4j-zero-day-mitigation-guide/), the affected file gets still determined under the following path: "C:\Program Files\Commvault\ContentStore\Updates\SP20-HotFix-4560\GxHomeDir\Base\DbJars\DbArchiveEngine.jar"

Is that an expected situation?

Regards,
Matthias

@Stuart Painter 

I have just tried to add the first hotfix to the cache and when doing it we get the following error message.

Please can you advise?

Badge +1

@Dave S  All of these are covered by the hotfix:

CVE-2021-44228

CVE-2020-9488

CVE-2019-3826

CVE-2019-17531

CVE-2017-5645

I’ll look into your CVE.

Was the latest CVE CVE - CVE-2021-45046 looked into as to whether this was covered under the hotfix ?

Userlevel 7
Badge +15

@James_Goodison

[Edited for clarity]

You have selected a folder a few levels too deep for the hotfix to get detected.

You need to select the folder containing the extracted hotfixes.

The Copy Software job will handle the import of the separate hotfixes.

Thanks,

Stuart

@Stuart Painter 
 

It doesnt seem to matter which level I do it at it fails with the same error. It also doesn’t allow to import zip files.

Can you provide a screen shot of yourself importing successfully?

Badge +1

Hi,
we have a question, we have applied the last fix for LOG4J but we saw that Commvault use version 2.15
 

but we can read on the web that hte Version 2.15 was most probably enough to protect us from attack but version 2.16 makes it certain !

do you know if Commvault will have rapidly a new fix for us with version 2.16 ?

Badge

Hi @James_Goodison 

You will need to apply both the minimum or higher MR level for your version plus all the hotfixes provided.

The hotfixes provided cover all affected agents for different client OSes, you need to import all the hotfixes to the cache and on installation, on the required hotfixes are provided.

If you are having trouble importing the hotfixes to the cache, please try running a copy software job on the folder containing the still zipped Log4J-Updates.zip.

Thanks,

Stuart

Hi Stuart, 
Apologies, please can you clarify your statement? 

I’ve installed the 11.20.82 MR, do I now need to install every hotfix in the folder to every agent? (Hotfix4562_Win32 and X64 AND Hotfix4563_Win32 and X64?)

Can these be installed remotely via copy software job etc or do I need to install these manually on each agent? Agents only use Windows SQL Server. 

 

Thanks in advance. 

 

OK, this was the critical step that wasn’t detailed enough in the directions.

The Copy Files job didn’t see the .zip file.

I unzipped the Log4J-Updates.zip file and pointed the Copy Files to the resulting folder.

This seemed to work.

I was originally pointing at the unzipped folders/files that were extracted from running the specific x64 hotfix exe.

Badge +1

Hi,

We have a question, we applied the last fix LOG4J but we saw that Commvault use the version 2.15

 

We can read on the web that the version 2.15 was probaly enough to protect us from attack but version 2.16 makes it certain !

 

Do you know if Commvault will have rapidly a new fix for us with version 2.16 ?

Userlevel 7
Badge +15

@m.rieder @Oriium 

Checking these queries internally, I’ll get back to you

Thanks,

Stuart

Badge

Apache made some recent changes at their end. is that been collaborated in the hotfix which CV is providing

Userlevel 3
Badge +13

Hello team,

Log4j 1.x has reached end of life and is no longer supported. Vulnerabilities reported after August 2015 against Log4j 1.x were not checked and will not be fixed. Users should upgrade to Log4j 2 to obtain security fixes.
https://logging.apache.org/log4j/2.x/security.html

does Commserve tomcat (Log4j1.x) comes with JMSAppender ?

https://bugzilla.redhat.com/show_bug.cgi?id=2031667

 

Reply