EVS security updates on Log4Shell vulnerability
Updated 04 February 2022 - 18:00 CET
EVS is actively responding to the reported vulnerability in the Apache Log4j 2 Java library dubbed Log4Shell. We are currently conducting a product-by-product analysis to determine if any are potentially impacted by the vulnerability. This is an ongoing investigation, so please check this bulletin page frequently for updates.
Log4j is an open-source Java logging library that is widely used in many applications and is present as a dependency in many services. This includes enterprise applications and numerous cloud services.
This vulnerability allows for unauthenticated remote code execution using the flow explained in the following article: https://www.lunasec.io/docs/blog/log4j-zero-day/
It is important to note that as part of the exploitation of this vulnerability, the vulnerable server must make an outbound request to the attacker owned server. Limiting outbound internet connectivity from web servers would prevent the full exploit chain.
Set to the JVM args log4j2.formatMsgNoLookups set to True in case not patched.
Sanitize log data before processing into Log4j
Products not impacted
|IPDirector||All||ElasticSearch version is not impacted thanks to usage of Java Security Manager *|
|IPD-VIA||All||ElasticSearch version is not impacted thanks to usage of Java Security Manager *|
|LSM-VIA||All||ElasticSearch version is not impacted thanks to usage of Java Security Manager *|
|Teradici Cloud Access||All|
* Log4J vulnerability scanners might detect impacted Log4J versions used by ElasticSearch. Elastic states for ElasticSearch versions used by EVS that, even though they are using impacted Log4J versions, Java Security Manager prevents from using this vulnerability for remote code execution. More info on : https://discuss.elastic.co/t/apache-log4j2-remote-code-execution-rce-vulnerability-cve-2021-44228-esa-2021-31/291476#elasticsearch-10
Meanwhile, defenders need to be diligent in detecting, hunting for, and investigating related threats. That’s the reason why EVS decided to provide the following workaround in order to clean the .jar file. The IPDirector is protected by the Java Security Manager and an extra layer of security is added by turning off JNDI lookup, a workaround that can prevent the exploitation of the Log4j vulnerabilities on most devices.
Known EVS impacted products & resolution
This list is under investigation and will be regularly updated.
|C-Next||Fixed||Impact in cloud services - Fix deployed||No patch needed on client side|
|IPLink for Adobe||2.x||Impacted||Workaround available||Patch pending|
|IPLink for Avid||1.0||Impacted||Workaround available||Patch pending|
|MAD||Fixed||Patch available. Please contact EVS project Managers|
|PMZ Cluster (VMWare vCenter)||All||Impacted (VCSA only)||
More information and detailed explanations on the working of this vulnerability can be found via the links below:
- Log4Shell: RCE 0-day exploit found in log4j, a popular Java logging package: https://www.lunasec.io/docs/blog/log4j-zero-day
- SANS ISC - RCE in log4j, Log4Shell, or how things can get bad quickly: https://isc.sans.edu/forums/diary/RCE+in+log4j+Log4Shell+or+how+things+can+get+bad+quickly/28120
- Greynoise is tracking the RCE attempts:
- CIRCL.LU TR-65 - Vulnerabilities and Exploitation of Log4j (Remote code injection in Log4j): https://www.circl.lu/pub/tr-65