Log4j Vulnerability - Please Post All Questions Here



Show first post

344 replies

Badge

@Gazza

If you use the copy to cache feature and push to clients, the ones not impacted will have nothing to install anyway. But MySQL, PostgeSQL and SAP at not impacted.

Well noted, thanks again @Jordan

Userlevel 5
Badge +11

@Gazza 

If you use the copy to cache feature and push to clients, the ones not impacted will have nothing to install anyway. But MySQL, PostgeSQL and SAP at not impacted.

Badge

Would it be beneficial to push out the log4j fix to all Oracle and SQL clients (we don’t use the cloud app) as a precautionary action?

I am unsure if Oracle ArchiveLog subclients fall under ‘Archiving’, so would rather be safe than sorry.

 

 

 

Absolutely, deploy to your CS and all Oracle and SQL clients. ArchiveLog does not fall under “Archiving” but better to be safe than sorry as well in case your DBA decides to do something :)

Thanks very much @Jordan, I’ll work on a rollout of the patch.

Do you know if this also affects MySQL, PostgresSQL and SAP agents as well? Might have to include these in the rollout based on your recommendation.

Userlevel 5
Badge +11

No problems at all @Michael Woodward 

Userlevel 3
Badge +9

Thanks Mike,

 

Can you clarify with the SQL and Oracle agents are they only vulnerable if the functions listed are used? or are all SQL / Oracle agents vulnerable.

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

 

We’re trying to prioritize our response to our customers at present.

 

@Michael Woodward

Only when used. So priority would be those that are used, followed by unused. 

Thanks @Jordan we’ll focus our energies on the cloud apps users (which is the majority) then move onto SQL / Oracle clients  Appreciate the quick reply

Userlevel 5
Badge +11

Thanks Mike,

 

Can you clarify with the SQL and Oracle agents are they only vulnerable if the functions listed are used? or are all SQL / Oracle agents vulnerable.

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

 

We’re trying to prioritize our response to our customers at present.

 

@Michael Woodward 

Only when used. So priority would be those that are used, followed by unused. 

Userlevel 3
Badge +9

Thanks Mike,

 

Can you clarify with the SQL and Oracle agents are they only vulnerable if the functions listed are used? or are all SQL / Oracle agents vulnerable.

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

 

We’re trying to prioritize our response to our customers at present.

 

Userlevel 5
Badge +11

Would it be beneficial to push out the log4j fix to all Oracle and SQL clients (we don’t use the cloud app) as a precautionary action?

I am unsure if Oracle ArchiveLog subclients fall under ‘Archiving’, so would rather be safe than sorry.

 

 

 

Absolutely, deploy to your CS and all Oracle and SQL clients. ArchiveLog does not fall under “Archiving” but better to be safe than sorry as well in case your DBA decides to do something :)

Badge

Would it be beneficial to push out the log4j fix to all Oracle and SQL clients (we don’t use the cloud app) as a precautionary action?

I am unsure if Oracle ArchiveLog subclients fall under ‘Archiving’, so would rather be safe than sorry.

 

 

 

Userlevel 5
Badge +11

Thanks Mike,

Seems like there is no agents at server:

[root@commandcenter ~]# find / -name "apache"
/var/lib/selinux/targeted/active/modules/100/apache
/usr/share/selinux/targeted/default/active/modules/100/apache
/opt/commvault/Apache/work/Catalina/localhost/ROOT/org/apache
/opt/commvault/Apache/work/Catalina/localhost/adminconsole/org/apache
/opt/commvault/Apache/work/Catalina/localhost/console/org/apache
/opt/commvault/Apache/work/Catalina/localhost/webconsole/org/apache
/opt/commvault/Apache/work/Catalina/localhost/manager/org/apache
/opt/commvault/Apache/work/Catalina/localhost/global/org/apache
[root@commandcenter ~]# find / -name "Log4j"
[root@commandcenter ~]#

Web console / command center does use Apache to service web pages however Log4j v2 won’t be there as it’s not a package that would be needed there.

Badge +1

Thanks Mike,

Seems like there is no agents at server:

[root@commandcenter ~]# find / -name "apache"
/var/lib/selinux/targeted/active/modules/100/apache
/usr/share/selinux/targeted/default/active/modules/100/apache
/opt/commvault/Apache/work/Catalina/localhost/ROOT/org/apache
/opt/commvault/Apache/work/Catalina/localhost/adminconsole/org/apache
/opt/commvault/Apache/work/Catalina/localhost/console/org/apache
/opt/commvault/Apache/work/Catalina/localhost/webconsole/org/apache
/opt/commvault/Apache/work/Catalina/localhost/manager/org/apache
/opt/commvault/Apache/work/Catalina/localhost/global/org/apache
[root@commandcenter ~]# find / -name "Log4j"
[root@commandcenter ~]#

Userlevel 7
Badge +23

Hello,

Is this Log4j Vulnerability affect Web Console/Command Center server?

Not specifically; only if those the server running the console also has the affected agents installed.

Badge +1

Hello,

Is this Log4j Vulnerability affect Web Console/Command Center server?

Userlevel 7
Badge +23

In what order should the hotfixes contained in the log4j_fix zip file be applied for a Windows environment? 4562 then 4563? In my certain case, its regarding version 11.20.

 

Thanks.

@NTCbrad , why not use Copy To Cache and push them, out that way?

 

Otherwise, manually install them in numerical order (though I don’t think it makes a difference).

Badge

In what order should the hotfixes contained in the log4j_fix zip file be applied for a Windows environment? 4562 then 4563? In my certain case, its regarding version 11.20.

 

Thanks.

Userlevel 7
Badge +23

@wstbackup to answer your other questions:

DBMinertool.exe is used for pseudo mounts and browse of tables for table level restore of SQL

Regarding those files, the hotfixes, once applied, should remove any affected files.  As noted above, there are some versions that are not vulnerable.

Userlevel 5
Badge +8

@wstbackup We are upgrading remaining older versions of log4j, but as of our current analysis they can be ignored since they are not affected.

Userlevel 3
Badge +6

@wstbackupNo that version is not an issue for this vulnerability.
 

 

Userlevel 2
Badge +2

Hey Mike

Hope you are keeping well

Over the last couple of days this has been causing some ripples. By the way, Commvault says it only affects the cloud apps packages / SQL agent / Oracle agent

But our internal vulnerability scan system was able to find this “Log4J” vulnerability on multiple server that didnt have any SQL/oracle agents installed. And know what when checking those servers it turned out to be the commvault folder that had this log4j file 
path : D:\program files\Commvault\ContentStore\Base\DBMinerTool

1. Can you help to know what is “DBminerTool” . What is it being used / installed for ?

2.  Checked some properties of this log4j file and the version is 1.2.17. Is it still vulnerable ?
     This may have been installed in any of the commvaults old MR / FR packages

3. Can we have these files removed from all the agents that had it detected ? Are these file here for a specific purpose or can they be deleted ?

 

 

Reply