Looks like Kalutra is using log4j and the version installed (2.11.1) used by elasticsearch match with a vulnerable one.
@jess do you know if Kalutra is impacted by this issue ? Is there a recommended/official way to patch this without breaking something ?
Version: Kaltura CE 16.14.0
Many thanks
HI @luca.guindani,
From the CVE (CVE - CVE-2021-44228):
Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.
So, in order for this bug to be exploited, one needs a service that is open to the outside world and, further, takes whatever payload was sent to it and passes that, AS IS, to log4j.
The Kaltura ES nodes do not need to be open to the outside world, irrespective of this particular issue. If your ES nodes are accessible from outside your internal network (where the Kaltura nodes reside), I recommend you address that, again, regardless of this log4j issue.
The log4j exploit was discussed in the ES forum (see Zero-day-exploit in log4j2 which is part of elasticsearch - #60 by sandeepkanabar - Elasticsearch - Discuss the Elastic Stack).
As I noted above, the important thing is to ensure the Kaltura ES nodes are not accessible from outside the cluster but if you’d like, you can also remove the JndiLookup class from the log4j-core JAR, like so:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
You may also update log4j to the latest version (2.16 at this point), I haven’t tried it myself but I don’t believe log4j introduced breaking changes between 2.11 and 2.16. After doing so, you should ensure everything is still working correctly (perform some search operations using the eSearch API service, etc) and compare the response with the one you received before making the changes.
Cheers,
Hello @jess,
Thanks for your quick answer !
I have a 16.14 all-in-one installation, and I have no fw rule for the es ports so it should be good. I also already deleted the class you mention from the log4j jar.
Cheers.