About the Log4j vulnerability CVE-2021-44228

Owned by Elias Brattli Sørensen
Last updated: Jan 03, 2022
2 min read

This page contains our advice and analysis of CVE-2021-44228. Note that it will we updated regularly as we learn new details about the vulnerability. In most cases, we refer to Atlassian’s documents about Log4j (these documents are update by Atlassian): (Multiple Products Security Advisory - Log4j Vulnerable To Remote Code Execution - CVE-2021-44228 || FAQ for CVE-2021-44228, CVE-2021-45046 and CVE-2021-45105). If Kantega SSO is vulnerable logging through Slf4j, then likely your entire system is vulnerable.

Is Kantega SSO Enterprise affected by the Log4j vulnerability CVE-2021-44228?

The answer is no, not by default. We have looked into our dependencies, and found out that Kantega SSO Enterprise is not affected since Atlassian on-prem runtime systems by default run older versions of Log4j out of scope for the vulnerability in question. Log4j is provided as a transitive dependency to Kantega SSO by the host system and used in a few cases in Kantega SSO Enterprise versions <= 5.1.1 and <=4.14.7. From versions 5.1.2 and 4.14.8, all logging is run through Slf4j.

Certain non-default Data Center / Server Atlassian host configurations may be affected by the vulnerability. You can read more about the incident for Atlassian systems in general in Atlassian’s FAQ: https://confluence.atlassian.com/kb/faq-for-cve-2021-44228-1103069406.html. Update 2021-12-21: Bitbucket Server and Data Center instances may be prone to CVE-2021-44228 (information leakage, not RCE) through Elasticsearch. Please read Atlassian’s security advisory for more details.

Update 2021-12-15: Consolidation of log facade in versions 5.1.2 and 4.14.8

Even though we are not directly vulnerable to Log4Shell, we were running the provided Atlassian-managed fork of Log4j 1.2.17 directly in a few classes instead of the Slf4j facade framework which is most commonly used in the app. The Atlassian-managed version log4j:jar:1.2.17-atlassian-3 is also said to be safe to another vulnerability CVE - CVE-2019-17571 8, as it does not have SocketServer class that is a problem in that old version.
In the patch releases of Kantega SSO Enterprise 5.1.2 (latest), and 4.14.8 (stable backport), we have consolidated our logging to be through the logging facade Slf4j only. This makes transitions to other framworks like Logback (which is run i Bitbucket) easier.
Any weakness in K-SSO logging will now be inherited through Slf4j due to a weakness in your entire Atlassian installation, and will have to be addressed on a system level.