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

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.

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

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

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

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

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

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.

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.

There is a KB article posted in MA, but it says that v1 isn’t affected; it was last updated nearly two days ago, though.

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 Brock, although I’m not sure that list is complete. This server has multiple log4j JAR files and it doesn’t have those packages installed. Hopefully it’s not used in these, either.

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

For what it’s worth, a scan of a server with the Cloud Apps package installed didn’t find any results for *log4j*.jar.

The developer of log4j said (on Friday) that 1.x is not vulnerable, via twitter.

Log4j 1.x does not offer a look up mechanism. Log4j 1.x sends an event encapsulating a string message to a JMS server. That is it. The attacker can supply whatever string he chooses but it remains a String. So not the same. At all.

There is official fix out for different versions, kindly check out with CommVault support. 

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

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

thanks @Stuart Painter for also posting it here.

@Stuart Painter / @Brock can you please make sure:

1. this information is send via mail towards customers
2. MA portal shows a message

Thanks!

Hello, 

in this case the agents for Oracle and SQL are affected. Would it work if I install the updates on the CommServer and then run an update on all Oracle and SQL agents or do the packages need to be deployed to each Oracle client ? 
The vulnerability should be fixed when the CommServe gets the update.
The media agents are not mentioned here. Do they also need the update ? 

it is recommended to push it on all…. SQL and Oracle systems will be affected one if they are using log4j version 2 

better to put it on all and do half work :)