Tim Webb
Vice President of Operations and a passionate technologist who thrives on merging software and marketing. Follow @timrwebb for periodic musing. A developer by birth, an optimizer by necessity, a forever believer in the ability of software to improve what you do.
Posted on Dec 14th 2021

Initial Analysis of CVE-2021-44228

A vulnerability in Apache Log4j2 was recently announced. To learn more about this vulnerability, visit the NIST National Vulnerability Database.

For transparency, Genuitec has conducted an audit over our server infrastructure, both with regards to our own internal infrastructure as well as our products that include server components, including CodeTogether and Secure Delivery Center. In all instances, we do not have usage of log4j2 on our servers.

Our methodology to confirm this involved both manual review of components and dependencies, as well as automated scans using tools that are designed to search within bundles, not solely exposed at the native file-system level.

For our Desktop software, in our CodeTogether plugins, we do not use log4j2 for any purpose nor is it included with our software. For MyEclipse, there is no usage of log4j2 in standard operations across all components of MyEclipse. See update below for clarification of the single presence of log4j2 and why it does not pose an elevated risk. For transparency, there are plugins for Eclipse-based IDEs that do optionally depend on the log4j2 and can be installed on top of MyEclipse via update site or alongside CodeTogether.

For more details on Eclipse IDE vulnerabilities:

Update 12/17/21


During analysis, there is a single presence of log4j2 in an embedded plugin in MyEclipse, specifically used as part of a client to OpenShift. This client is brought in as part of a transitive dependency, though it does not specifically use log4j2 in MyEclipse normal usage. This log4shell instance is only used if you explicitly turn on tracing options for the org.jboss.tools.openshift.client plugin and are also using the OpenShift client. In addition, as it is not logging data from untrusted sources, there appears no detected vulnerability at this time, even if you had explicitly turned on logging.

If you are concerned, we suggest running the following tool which can remove the offending JndiLookup class without impacting any functionality.

java -jar logpresso-log4j2-scan-2.1.2.jar --fix "[me-install-dir]"

CodeTogether Container for On-Premises Installations

Log4j2 is present in jvb.jar, which is part of the Jitsi Videobridge – it is not used at runtime.

A write-up regarding Jitsi and CVE_2021-44228 can be found here:

Specifically, we do not enable callstats for various reasons, one being as it would expose behavior of A/V calls outside of your network.

To avoid confusion from false positive scans, we will be upgrading the component of JVB officially in our next CodeTogether 5.1 release, expected at the start of January.