good news that CV software isn’t affected because version log4j 1 is used.
But on the other hand:

Hi All 

We have been running deeper reviews since this was reported, and we will be posting an official notice on this CVE within the next few hours to our BOL Security notices page.   

As noted in some of the earlier threads, there is not an active, operational risk.

We do not actively use or load the Log4j service.   

Several of the installed client packages will show up under a file scan with the affected files as part of the library - but those are static passive files as part of some of the libraries.

The affected clients

1. Cloud Apps package
2. Oracle agent with the Database archiving, data masking, and logical dump backup installed
3. Microsoft SQL Server agent with the Database archiving, data masking, and table-level restore installed

The notice will include new hotfixes that can be used to remediate those clients and we will automatically remove the affected files.

Thank you 

Brock

(Brian Brockway, Global CTO, VP, Commvault) 

Thanks everyone for the comments, as @Hussain has notified, we do have an official statement published in the last hour:

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

Security Vulnerability and Reporting

Security Advisories

CV_2021_12_1: Vulnerability in Apache Log4j Logging Libraries Impacting Commvault Products

Advisory ID: CV_2021_12_1

External Reporting IDs: CVE-2021-44228

Issued On: December 11, 2021

Updated On: December 11, 2021

Severity: Critical

Version: 1.0

Description

A critical vulnerability has been found on Apache Log4j logging libraries. For more information about this vulnerability, refer to the following report:

CVE-2021-44228: Apache Log4j2 JNDI features do not protect against attacker controlled LDAP and other JNDI related endpoints

Affected Products

This vulnerability may affect the following products:

• 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

Resolution

An update has been issued to remove these vulnerable log4j versions from the affected Commvault packages.

Download and install the following updates from the Commvault store for your Feature Release on the affected client computers.

Thanks,

Stuart

Hi @M Scheepers 

Thank you for the question, there is a lot of activity around this one right now.

Commvault is not affected by this log4j vulnerability, tracked as CVE-2021-44228.

After inspection we found that the Commvault platform is not using the log4j packages versions as documented in the vulnerability and is therefore not affected by this vulnerability.

Thanks,

Stuart

@Stuart Painter That is the reason that is would suggest give a official statement that the Commvault software is not effected by this vulnerability.

I agree, I came here to find confirmation of this and was expecting an official statement that I can take to our security team.  I really encourage Commvault to get that out by Monday, so that Internet searches will find it.

Looking at the official Advisory referenced above Security Vulnerability and Reporting (commvault.com) it is still not entirely clear what the correct procedure to remediate this issue is.

The remediation says, “Download and install the following updates from the Commvault store for your Feature Release on the affected client computers”

So, if you are on FR 11.24.xx, the remediation seems to suggests going to FR 11.24.23, but then then it refers to an “Upgrade” file named, “11.24 Log4J Fix”.

Does this mean that the a minimum requirement is to first update your Commcell to 11.24.23, then you need to run a specific separate Upgrade file against those client computers that have the Cloud Apps package, Oracle Agent or SQL Agent?

I would hope that a consolidated 11.24 hotfix pack that includes the fix might be released to simplify this so as long as you upgrade to that FR 11.24.xx hotfix pack in one -go so you are covered without needing to then manually upgrade individual clients.

If Brock or the product team could clarify the exact remediation process envisioned, or whether a consolidated Feature Release Hotfix pack that includes the fix for a one-step upgrade (as much as upgrades are ever one-step) it would be greatly appreciated.

Regards,
M

If you are just using MSSQL and Oracle streaming or IntelliSnap backup, then you shouldn’t be impacted at all. Log4j packages may be discovered during security scan but they are not actually running/active. 

doing a file search in the commvault install folder I can see there’s multiple log4j libraries in the

ContentStore\MessageQueue\lib\optional folder, which included version 1.2.17.

According to this CVE log4j 1.2.0 to 1.2.17 are impacted by this via CVE-2019-17571

https://nvd.nist.gov/vuln/detail/CVE-2019-17571

Can you confirm if commvault is indeed not impacted by this or patch will be provided to mitigate this issue.

thanks @Stuart Painter for also posting it here.

Can someone document the steps which needs to be taken ?

Also , if we are not using archiving & masking do we need to upgrade feature release for SQL and Oracle Clients .

Hi all,

The minimum Maintenance Release needs to be installed first on CS/MA/potentially impacted clients. Then the additional update patch needs to be installed on top to the clients. The Log4j packages are installed on clients, not CS/MA (unless CS/MA also had the impacted agents).

These patches will eventually be rolled into a Maintenance Release just like any other Commvault official patches according to release cycle. 

It is being released out of band/cycle here due to the severity of the vulnerability and potential of impact.

Thank you

Edit: HotFix2763 will need to go on CS and Win clients whilst Hotfix 2764 and 2765 goes on clients (Unix only for 2764 and Unix/Win for 2765)

Hi @M Scheepers 

Yes, we’re certainly seeing lots of activity in Customer Support here over the last 24 hours or so with this one.

My understanding is that while we do have log4j packages present in Commvault, these are earlier versions and this current vulnerability CVE-2021-44228 only affecting certain v2 versions.

Thanks,

Stuart

Hi to all,

Is there any official note by Commvault?

regards

michele

@Stuart Painter :

If log 4j 1.x is EOL , why did Commvault use it in its packages ? 

Are we 100% sure that log 4j 1.x versions are not impacted by this vulnerability or we are saying it because it is EOL ?

Please share the official response from CommVault regarding this vulnerability  ? 

Regards, Mohit

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

C:\>dir /s E:\*log4j*.jar
 Volume in drive E is Server Applications

 Directory of E:\Program Files\Commvault\ContentStore\CVAnalytics\DataCube\app\webapps\server\WEB-INF\lib

06/22/2021  05:12 AM           481,403 apache-log4j-extras.jar
06/22/2021  05:13 AM           525,106 log4j.jar
06/22/2021  05:14 AM            16,710 slf4j-log4j12.jar
               3 File(s)      1,023,219 bytes

 Directory of E:\Program Files\Commvault\ContentStore\CVCIEngine\CvPreviewHome\app\webapps\server\WEB-INF\lib

06/22/2021  05:12 AM           481,403 apache-log4j-extras.jar
06/22/2021  05:13 AM           525,106 log4j.jar
06/22/2021  05:14 AM            16,710 slf4j-log4j12.jar
               3 File(s)      1,023,219 bytes

 Directory of E:\Program Files\Commvault\ContentStore\CVCIEngine\CvPreviewHome\webapps\CvContentPreviewGenApp\WEB-INF\lib

11/03/2021  05:29 PM           525,110 log4j-1.2.17.jar
               1 File(s)        525,110 bytes

     Total Files Listed:
               7 File(s)      2,571,548 bytes

same here, installed the Fix on MA (v11.22.54)

Pre:

C:\Users\Administrator>dir /s d:\*log4j*.jar
 Volume in drive D is DATA
 Volume Serial Number is 789B-8583

 Directory of d:\Commvault\ContentStore\Base\vmheartbeatmon\zookeeper\lib

25.10.2017  20:43           481.535 log4j-1.2.16.jar
25.10.2017  20:43             9.753 slf4j-log4j12-1.6.1.jar
               2 File(s)        491.288 bytes

Post:

C:\Users\Administrator>dir /s d:\*log4j*.jar
 Volume in drive D is DATA
 Volume Serial Number is 789B-8583

 Directory of d:\Commvault\ContentStore\Base\vmheartbeatmon\zookeeper\lib

25.10.2017  20:43           481.535 log4j-1.2.16.jar
25.10.2017  20:43             9.753 slf4j-log4j12-1.6.1.jar
               2 File(s)        491.288 bytes

UpdatInfo.log snippet:

16652 22280 12/13 16:37:17 ###      User selected to start Simpana services
16652 22280 12/13 16:37:17 ###      Deleting file D:\Commvault\ContentStore\Base\DbJars\log4j-api-2.3.jar
16652 22280 12/13 16:37:17 ###      Deleting file D:\Commvault\ContentStore\Base\DbJars\log4j-core-2.3.jar

the same log entries, even if the path is not present.

Tried on different clients (Cloud App, SQL, Oracle)

Is the Fix really final?

Regards,

Alex

Would appreciate this too. Never had to do out-of-band updates manually before, but probably the order is to install the updates as from downloadpackage in proper order (4561, 4562, 4563) and ignore any overlap between them It would really be convenient to push this from commcell instead of manually on each individual client…..

First download the latest MR of your current Feature Release. Wait until Download Software job completes.

Then run the copy software job againt the folder containing log4j packages. Wait until Copy Software job completes.

Your software cache is ready for remote deployment.

Thanks @Stuart Painter for the quick reply.. Maybe its good to official communicate this, a quick search found several log4j packages. Just to be sure i can imagine that several people getting questions from they Sec teams.

Add me to the list of people demanding a formal statement.

https://documentation.commvault.com/hitachivantara/v10/article%3Fp%3Dproducts/web_console/external_authentication/third_party_integration.htm+&cd=6&hl=en&ct=clnk&gl=us

I believe the page above was modified to remove references to logj4 under the libraries used.

EDIT: Apologies, I was searching LOGJ4 instead of LOG4J, user error. 

If you run Greenbone against Commvault it finds heaps of older, unpatched open source software packages like the log4j 1.x.  We need to hold them more accountable.

Commvault must publish an official document for this issue.

Hello @Stuart Painter we expect commvault to announce and publish this in maintenance advantage home page.