JAVA EXPLOIT – vulnerability with Log4j

By Marina Tucker, Director of Support Services and Customer Success

Continue Following this Blog Post for Live Updates!

On Friday, December 10, 2021, CHESA received notice that there is a vulnerability with Log4j. “Log4j is a Java-based logging audit framework within Apache. Apache Log4j2 2.14.1 and below are susceptible to a remote code execution vulnerability where a remote attacker can leverage this vulnerability to take full control of a vulnerable machine.” CHESA Support is evaluating all environments for any vulnerabilities related to the Log4j. We have reached out to our vendors to gather information on if their software presents this vulnerability.

The following vendors have identified vulnerabilities or provided feedback. If there is a vulnerability in your environment CHESA support will open a case under your service contract to address the vulnerability.

Amazon Web ServicesAWS BlogUsing AWS security services to protect against, detect, and respond to the Log4j vulnerability | Amazon Web Services. December 20, 2021: The blog has been updated to include Amazon Route 53 Resolver DNS Firewall info.

ArchiwareP5 and Pure are not affected by the Java Log4j vulnerability. P5 and Pure do not use any Java code, that also excludes the use of the Java Log4j library. It is thus not affected be the Log4j vulnerability. Both products are based on the Naviserver that is written in the C programming language. 

AsperaAspera does not use log4jv2. The java applications use log4j-over-sl4j – which uses the same API interface as log4j but it is a different software component. There is one part of the java stack that does use log4jv1 – that is the trapd component when it is interfacing with the hdfs:// type storage. There are not many customers using HDFS. Since this is log4jv1 it is also not vulnerable.

Avid – December 20, 2021 Update: Avid is aware of the recently reported Apache Log4j RCE vulnerability.
CVE-2021-44228 – Please review the following document for more information, and follow Avid Best Practices for isolating your Avid systems from the internet.

Codemill
Accurate.Video:
None of the Docker images that we currently distribute as part of Accurateplayer or Accurate.Video includes any version of log4j. Our product, Accurate Player Vidispine Edition (APVE), did have an issue with one of its renditions but this has been fixed and rolled out.
Cantemo:
Cantemo, Vidispine, and any other components are not impacted directly by this vulnerability. In Cantemo we have the following components that use Java: Elasticsearch – no remote code execution issue. Rules Engine 3: Tomcat/Activiti – using an older log4j that is not affected Vidispine and its components like Solr – no remote code execution issue. We will still release upgrades for all Portal versions under maintenance with an upgraded Elasticsearch, and potential automatic configuration changes to other components. Vidispine’s analysis here

If you want an immediate fix you can apply configuration changes to Elasticsearch here– and Vidispine+Solr (see Vidispine support message above).

Dalet – Flex: Flex itself is not affected, however, two third-party services are. Flex Java services and apps use SLF4J with logback, not log4j2, read here -vulnerability-and-spring-boot not affected. Third-party services exposed to this vulnerability: Elasticsearch and Logstash. This documentation explains more about the log4shell vulnerability in the context of these two services. Entire Security Bulletin and Remediation Instructions here

File Catalyst – At this time, FileCatalyst products are not impacted by this vulnerability. For the latest guidance.

Iconik – We determined that we had internal components which were running the vulnerable version of log4j but with a configuration that most likely made them not vulnerable (a recent enough Java with default settings which made it not execute any malicious code). We did however proceed to patch the vulnerable software to be doubly sure. We have also investigated our logs and have not seen any indications that there have been any exploits though we do see active attempts at exploitation from various sources.

IPVPlease rest assured that the use of Solr (read more here) in Curator is not exposed publicly on Curator systems. However, we do understand that the vulnerability is concerning so we’re recommending a patch to further mitigate any risk. For more info
You will need to do the following: Edit the Solr command file found in [Curator Server InstallationPath]\Server\Solr\bin\solr.in.cmd by adding the following line: set SOLR_OPTS=%SOLR_OPTS% -Dlog4j2.formatMsgNoLookups=true
Following this, restart Curator Server. To confirm the setting has been changed successfully, check the Solr Admin page on your Curator Server machine (located at: http://localhost:8983/solr/#/ ) to find the following under the JVM Args heading: “-Dlog4j2.formatMsgNoLookups=true”

Levels Beyond On December 10, 2021 A Log4j Security Vulnerability known as CVE-2021-44228 was brought to the attention of our TechOps and SecOps engineers. After a full investigation of REACH ENGINE code, packages, systems, environments, completed shortly after notification, it was determined that all versions of Log4j libraries currently leveraged are not impacted by the reported vulnerability. We at REACH ENGINE take security very seriously and continually monitor the health of our code libraries and rapidly respond to any information of risk for our customer or their business. For now, all REACH ENGINE code packages are without impact however we will continue to be vigilant and follow the issue appropriately.

North Shore AutomationNSA Software – In addition, NSA does not use Log4j in any of our software. NSA VM deployments – A previous and unaffected version was installed as part of the base CentOS install on some older NSA VMs. It is an older version (1.2.x) and is not impacted by this vulnerability. This vulnerability was introduced in v2.x. The old version can safely be removed from the VMs without impacting any of the software running on them with the following command: sudo yum remove log4j

Open-E In order to ensure the highest levels of security for our users, both Open-E JovianDSS and Open-E DSS V7 have been checked for any possible vulnerabilities related to the Log4Shell exploit. Despite the fact that our products’ core systems don’t contain the affected Log4j Java library, we’ve conducted multiple tests to check if the 3rd party management tools (which are run in cases where the related hardware is installed on the server) have not been affected.

Prime Stream – PENDING

Quantum and CatDV – Read Bulletin here Quantum is aware of the recent Common Vulnerabilities and Exposures (CVE) database entry regarding the open-source Apache Log4j utility and is actively monitoring the issue and evaluating its impact on Quantum products.

Scale Logic – PENDING

Signiant – https://support.signiant.com/hc/en-us Please note that we have investigated the Apache Log4j security vulnerability (CVE-2021-44228) and confirmed that NONE of the Signiant products are exposed or impacted by this vulnerability.

Studio Network Solutions – At this time we have not discovered any versions of our products that are vulnerable to this exploit. Our Statement

Telestream – Telestream has determined that the following products are not affected: Vantage, ContentAgent, Aurora, Cerify, Vidchecker, CaptionMaker, MacCaption, GLIM, Switch, Wirecast, Wirecast Gear, ScreenFlow, WFM, PRISM, Signal Generators, MPEG Analyzers, DIVAView, MassStore, iVMS, iVMS ASM, InspectorLive, Cricket, Geminus, IQ Media Monitor, Surveyor TS, SurveyorABR Active, PLM, cVOC, cPAR, Sentry, Sentry Verify, Medius, Consul and our Telestream Cloud Services . For products DIVACore, DIVAConnect, Kumulate, SurveyorABR Passive and Inspect 2110, contact  for more information.

If you have any questions, please open a case at chesa.force.com or call the support line at 410-705-6286.

Respectfully,

Marina Tucker – Director of Support Services and Customer Success

 

 

   

 

 

 

 

 

 

 

« BACK TO BLOG POSTS