VERTICA SECURITY BULLETIN - A potential vulnerability has been identified: Apache log4j library used
SUPPORT COMMUNICATION - SECURITY BULLETIN
Potential Security Impact: remote code execution
VULNERABILITY SUMMARY
A potential vulnerability has been identified: Apache log4j library used by Vertica Server.
The vulnerability could be exploited to allow remote code execution.
CVE References: CVE-2021-44228
Please reference https://forum.vertica.com/discussion/242515/vertica-potential-security-vulnerability-apache-log4j-cve-2021-45046#latest for latest updates.
SUPPORTED SOFTWARE VERSIONS (ONLY impacted versions are listed):
Vertica Server – all versions
CVSS Version 3.1 Metrics:
Reference V3.1 Vector V3.1 Base Score
CVE-2021-44228 N/A N/A
RESOLUTION:
Vertica Server
You can either apply the patch or perform the workaround.
Apply Patch
Two components in the Vertica product contain a vulnerable log4j library, Management Console (MC) and Kafka. Both are being modified to use a patched version of log4j (log4j.2.15.0). All Vertica versions currently under Committed Support (10.0, 10.1, and 11.0) will be patched and hotfixes will be available very shortly.
The workaround below will mitigate the problem while you wait for the patch.
Workaround
This workaround can be applied to the Vertica Management Console and Vertica Kafka components independent of the Vertica version.
On every server node, you need to update the Kafka scheduler.
zip -q -d /opt/vertica/packages/kafka/lib/log4j-core*.jar org/apache/logging/log4j/core/lookup/JndiLookup.classOn MC node, you need to fix the Kafka scheduler it wants to use:
zip -q -d /opt/vconsole/vendor/vertica/kafka/lib/log4j-core*.jar org/apache/logging/log4j/core/lookup/JndiLookup.classAnd lastly, the MC itself uses log4j which is bundled into the webui.war file and unzipped by startup into /opt/vconsole/temp/*. So, you need to change the .jar inside the .war and also purge the temp space so it re-extracts.
mkdir /tmp/war cd /tmp/war cp /opt/vconsole/lib/webui.war . unzip -o webui.war zip -q -d WEB-INF/lib/log4j-core*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class zip -r -u webui.war WEB-INF sudo /etc/init.d/vertica-consoled stop cp webui.war /opt/vconsole/lib/webui.war rm -rf /opt/vconsole/temp/* sudo /etc/init.d/vertica-consoled start
Vertica Accelerator (Vertica as a Service)
Vertica Accelerator is not impacted by this vulnerability.
Comments
Hello,
Do you have suggestion for Voltage Vertica ?
I found Voltage for Vertica using Log4j also
voltage-pp-0000 /]# find . -name "log4j-core-*"
./opt/splunk/bin/jars/vendors/spark/2.3.3/lib/log4j-core-2.13.3.jar
./opt/splunk/etc/apps/splunk_archiver/java-bin/jars/vendors/spark/2.3.3/lib/log4j-core-2.13.3.jar
With regard to Voltage SecureData see the communication published here:
https://community.microfocus.com/cyberres/b/sws-22/posts/summary-of-cyberres-impact-from-log4j-or-logshell-logjam-cve-2021-44228
Hi,
Our security scanner appears to pick this up on both MC as well as the cluster nodes. After a closer look, I can see the vertica packages themselves ship with the vulnerable version.
Vertica installs this Kafka package by default when you create a database, example output from a newly created db.
Does this not leave the Database Server itself vulnerable? Or only for those actively using the Kafka integration?
Kind Regards,
Hi, It does NOT leave the Database Server vulnerable, these files are not used by the Veritca server directly. These files are available for the Kafka scheduler integration. The workaround will remove the vulnerable files from the scan detection.
Corrected post.