We’d like to inform that OpenVidu is NOT affected by Log4J vulnerability (CVE-2021-44228). Neither OpenVidu nor any of its dependencies includes Log4J. There is no need to make any changes to the OpenVidu services configuration.
So Elasticsearch and Kibana are not susceptible of RCE vulnerability (OpenVidu uses 7.8.0 version since version 2.16.0). In any case, if you feel paranoid you can use this environment in /opt/openvidu/.env and you should be fine:
UPDATE 16 December 2021
Now it seems like -DDlog4j2.formatMsgNoLookups=true its not enough to cover all attack vectors. The good news its like Elastic said in another blog that Elasticsearch is not susceptible of such attacks to be executed.
Yesterday a new CVE-2021-45046 has been discovered, and also the parameter -Dlog4j2.formatMsgNoLookups=true seems to not cover all attack vectors.
I’ve created a patch to still using Elasicsearch 7.6.2 or 7.8.0 so this new CVE is also covered.
You just need to replace the docker image used in your deployment in /opt/openvidu/.env:
If your deployment is using 7.8.0 you can replace the docker image to a new one patched:
This image is exactly the same as the official one from elasticsearch, but a patch is being applied. You can check how images are patched here:
The log4j version is updated directly in the image.
Elasticsearch recommends to update to version 7.16.2, but, we can’t enforce such upgrade because this would break compatibility with AWS OpenSearch, metricbeat and filebeat.
I want to clarify that this is just an additional protection for Elasticsearch, but at the moment and regarding what Elastic team says, Elasticsearch is not compromised. This is just a patch to cover for current and future CVEs related with JNDI lookups and log4j… An additional protection just in case.