UPDATE 12/21/2021
Log4J (CVE-2021-45105) Update:
Yesterday, Monday December 20, 2021, Apache made a new Log4J patch (Log4J 2.17) available which addresses a condition where log4j does not always protect from infinite recursion in lookup evaluation when the logging configuration uses a non-default Pattern Layout with a Context Lookup. If exploited, this could cause a Denial of Service for the collector service only. Vopta’s use of Log4J does not use this non-default configuration, and when correctly deployed will not have any exposure to inbound traffic from the internet, so the likelihood of this being attacked is very low, however, we have released a new 4.8.3 patch which includes the Log4J 2.17 update to address this vulnerability.
The collector available in the Vyopta Admin Portal is now updated with this patch.
UPDATE 12/15/2021
Log4J (CVE-2021-44228) Update:
Today, Apache released patch (Log4j 2.16.0) due to the previous patch being incomplete for certain non-default configurations, resulting in a new CVE (CVE 2021-45046).
Although Vyopta does not use any JNDI in our logging services, we have released a new patch which includes the Log4J 2.16 update mitigating all currently-known elements of the existing log4j RCE vulnerability (CVE-2021-44228, CVE 2021-45046) and we recommend all customers update their collectors with the new release 4.8.2 which is available in the Vyopta Admin Portal.
If you need any assistance, please open a ticket in the support portal and we will be happy to assist.
Original Message
Vyopta has become aware of a high impact RCE for the log4j logging package (CVE-2021-44228).
Details:
Our method of implementation makes the likelihood of the exploit low. The collector runs as a stand-alone service that pulls data from external sources (UC infrastructure and devices), and sends that data to the Vyopta platform in the cloud. It uses log4J to dump debug, error and other types of messages to a local file. These logs are also sent to the Vyopta platform for our support teams to study for support needs.
Some types of UC infrastructure and devices post data to the collector (via http and ftp) which is also shipped to the Vyopta platform. This is the only situation where the collector is listening for messages. Only if a message is sent to a specific path on the specific listening ports, and trace logging is enabled, there is a likelihood that an exploited message makes it into the logging system.
Remediation:
Due to the high visibility of this vulnerability and the existence of readily available exploit code in the wild, we have produced a patch for the vulnerability which is available for immediate release. We recommend that customers download and implement this patch as soon as possible.
1. Should you determine that a patch or update is not feasible at this time, there is also a potential mitigation which may be easily applied and we recommend at minimum all customers perform this mitigation (setting the formatMsgNoLookups=true property) as shown below:
Add this line to vyoptacollector.xml file before the ending </configuration> tag:
<property key="vm.args">-Dlog4j2.formatMsgNoLookups=true</property>
If the file already has an entry for vm.args, this new setting can be appended so:
<property key="vm.args">-Dsomeprop=someval -Dlog4j2.formatMsgNoLookups=true</property>
Save the file and restart the collector.
2. Alternatively, you can upgrade to Vyopta Data Collector 4.8.2 where this issue is addressed.
If you would like to download the patched collector, you can download the latest version of the Vyopta collector from the Admin Portal.
To upgrade the collector, you can follow the steps located in this knowledge document: Manual Collector Upgrade with Roll-Back - Best Practice
Comments
Please sign in to leave a comment.