The Log4Shell vulnerability: here’s what you need to do next

As you may already have seen in the news, a critical vulnerability has been found in the Log4j library. CVE-2021-44228, dubbed Log4Shell, affects versions of Log4j 2.0-beta9 up to 2.14.1. The issue has been fixed in Log4j 2.15.0 and above.

Log4Shell is a critical vulnerability, with a CVSSv3 score of 10 out of 10, in the popular Log4j2 logging library used by many Java (and other languages that use the Java Virtual Machine) applications. The vulnerability allows Remote Code Execution (RCE) and information leakage from servers that use vulnerable versions of Log4j. Log4j is vulnerable because it uses JNDI to perform lookups when logging messages containing the string "${jndi:...}".

The impact of this vulnerability is widespread. Many vendors who use Java technologies are affected. The focus of the rest of this post is on Adaptavist's customers. If you write or operate Java-based applications you should make your own assessments of risk based on the information provided. Microsoft and others have provided assessments of impact.

Marketplace Products

Adaptavist's apps on the Atlassian Marketplace are not directly impacted by this issue and there are no actions needed to address the vulnerability for our apps.

Our Server and Data Center products use the logging libraries provided by the host application and do not provide their own logging libraries. For Jira, Confluence, and Bamboo this is log4j 1.2 and Bitbucket uses Logback instead of Log4j for logging. Atlassian has produced a knowledge base article with further information.

ScriptRunner Scripts

One question we have had from ScriptRunner customers is if a script could introduce the vulnerability. Due to the cloud architecture, ScriptRunner cloud customers cannot be affected. 

For Server and Data Center scripts, while technically possible to use a vulnerable version of Log4j it would require the customer to actively use Log4j 2, putting it on the application classpath via modifying their Jira, Confluence, Bitbucket, or Bamboo installation, or using the @Grab annotation in a script. This is a highly unlikely scenario, as there is already a logger available to all scripts, and would only affect code-paths that used that script, making it an even more unlikely target. 

Customers that are worried about this scenario should review all of their scripts for use of the @Grab annotation.

Adaptavist Managed Services

We appreciate that incidents like this can be a cause for concern. In response to the Log4Shell vulnerability, we are undertaking a thorough risk assessment across all our customers. We will speak directly with customers that need to apply a patch or require mitigation. If you have not heard from us, please be assured no further action is required.

Patch as soon as possible

Log4Shell is a very serious issue that is currently being actively exploited in multiple ways. As soon as any vendor produces an update, we recommend you apply them immediately.

If you have modified the logging configuration of your Atlassian installations (except Bitbucket Server/Data Center) you should check that there are no lines containing org.apache.log4j.net.JMSAppender. 

Stay up to date with trusted sources of information

As well as reporting on the initial disclosure, LunaSec has published an excellent guide to detection and mitigation of the Log4Shell vulnerability. There is a lot of misinformation around this vulnerability. Two things that have repeatedly come up that require clarification are:

1. Running an up-to-date version of Java is not sufficient to fully mitigate the issue.
2. Log4j 1.x is not vulnerable to this issue, but it does have other vulnerabilities which require mitigation.

Note to Bitbucket Server/Data Center customers

Bitbucket Server/Data Center contains Elasticsearch. Elasticsearch is vulnerable to CVE-2021-44228, but not to remote code execution according to Elasticsearch. Until Atlassian produces an updated version of Bitbucket with an updated version of Elasticsearch we recommend you apply the mitigation detailed here.

Update 2021-12-16: Atlassian has released an update to their advisory that confirms this. Please refer to their notice for updated versions of Bitbucket Server/Data Center. Atlassian has provided instructions on how to apply the workaround described by Elasticsearch if you are not able to upgrade immediately.

Please note the contents of this page are the result of our current knowledge and are provided AS IS without warranty of any kind.