Update: Atlassian's Investigation on CVE-2021-44228

In response to CVE-2021-44228, Atlassian has been diligently investigating the risk posed to our customers and partners. At this time, we can confirm that Atlassian’s Connect for Spring Boot (ACSB) is not vulnerable to this vulnerability. As a refresher, ACSB is one of Atlassian’s frameworks that handles tasks like JWT authentication and signing, persistence of host details, etc. We linked our public repository here.

Other services made available to partners to develop apps, such as Forge and Atlassian Connect for Node.js Express, are also not vulnerable.

We are continuing to monitor the situation for our apps, and we will provide updates as soon as we have them. In the meantime, Atlassian strongly recommends that all partners review each of their apps, specifically to confirm that you’re using the latest org.apache.logging.log4j:log4j-core to version 2.15.0 or higher. To check your repositories, you may choose to use Snyk’s public and free scanning tool, which we’ve linked here: Snyk | Developer security | Develop fast. Stay secure.

13 Likes

Out of curiosity: you seem to only discuss the impact of CVE-2021-44228 on the Atlassian Marketplace Partner infrastructure, mostly the apps and what we as partner can do.

Obviously, many of us are also wondering whether Atlassian host products (Jira, Confluence, etc) are vulnerable, and if such, which versions. We might be getting requests from customers (esp. the solution partners) and it would be great if we can point them to official Atlassian communications regarding the impact of this vulnerability.

8 Likes

Agree - InfoSec wants to know if our Jira and Confluence self-hosted servers are vulnerable.

1 Like

I know of several divisions within my company that have their own deployment of Jira and Confluence (Data Center edition), and there are questions being raised about the impact of CVE-2021-44228.

Atlassian - would you kindly clarify if this vulnerability impacts any on-premise Atlassian products, and if so, which versions are affected and what can be done to mitigate the impact from this exploit?

Our investigation into cloud and on-prem products is ongoing, but this FAQ provides current status: FAQ for CVE-2021-44228 | Atlassian Support | Atlassian Documentation

9 Likes

Hi,

is log4j:jar:1.2.17-atlassian-3 affected on the server / DC platform? I notice this package is included as a provided build dependency in com.atlassian.jira:jira-api:jar:8.20.0 .

According to Log4j – Apache Log4j Security Vulnerabilities, the affected log4j-core versions are >=2.0-beta9 and <=2.14.1 . So at first glance this package it is not affected, unless if introduced via the customization done for log4j:jar:1.2.17-atlassian-3?

Hope you can clarify this, to be sure.

With kind regards,
Edwin Rozie

Hi, everyone. We recently published an advisory that should answer ongoing questions about this vulnerability’s impact on our products. You can read it here.

As part of this advisory, we also included impact on apps. Importantly, we have started to notify apps vulnerable to CVE-2021-44228 via AMS. Given the severity of this situation, each vulnerable app must address the issue within 72 hours of being discovered. To ensure customer data is protected from this incident, Atlassian will pause cloud apps that do not address the issue, and inform customers who have vulnerable apps installed.

We encourage all cloud, DC and server apps vulnerable to CVE-2021-44228 to rotate their shared secret, and to directly communicate with customers themselves about their efforts to mitigate the situation. You can contact Ecosystem Security via DEVHELP to coordinate.

4 Likes

Hi @JakeComito ,

In the official communication you mention that on on-premise, log4j version 1.2.17 is safe. We are currently using Atlassian’s provided version 1.2.16 in our on-premise apps. Can you confirm me that this fork is also not vulnerable to CVE-2021-44228?

Thanks

Do you know that 1.2.16 AND 1.2.17 are vulnerable to something else CVE - CVE-2019-17571?

(I understand that log4j:jar:1.2.17-atlassian-3 is safe, as it does not have SocketServer class that is a problem)

Also, 1.2.x could be vulnerable to CVE-2021-44228 if you have JMSAppender configured and some other conditions met

@JakeComito If Atlassian scans an app and the result is “not vulnerable”, then the app vendor will not be notified, correct?

In other words, if the vendor doesn’t hear from Atlassian, then it is either because its app wasn’t scanned or it was scanned, but the vulnerability was not found in it?

(By the questions, I wanted to suggest that maybe Atlassian should notify the app vendor even if “we scanned your app and it looks OK”.)

2 Likes

@JakeComito Naive question: if a Jira Server/DC or Confluence Server/DC app:

  1. does not ship its own Log4j version in the JAR
  2. does not ship its own Log4j configuration
  3. does not alter the Log4j configuration from code (run-time)

…but:

  1. let the Atlassian host product inject Logger instances into the app classes
  2. the app writes to the log only through those Logger instances

… can we safely say that the app itself is not vulnerable unless the Atlassian host product is vulnerable? Is it true?

4 Likes

Hi, @dusan.spaic. Yes, that’s correct. 1.x is not vulnerable, which includes our fork.

1 Like

Yes , Atlassian products that use Log4j 1.x are only affected if all of the following non-default configurations are in place:

  • The JMS Appender is configured in the application’s Log4j configuration
  • The javax.jms API is included in the application’s CLASSPATH
  • The JMS Appender has been configured with a JNDI lookup to a third party. Note: this can only be done by a trusted user modifying the application’s configuration, or by trusted code setting a property at runtime.

This is mentioned in our advisory as well - FAQ for CVE-2021-44228 | Atlassian Support | Atlassian Documentation

1 Like

Thank you for this clarification.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.