This is a living document (Last Updated 09:55 ET Dec 11th 21), and we’re working to update it as we find more information. If you have feedback, please feel free to email boris@atlasauthority.com

Official Responses

Official response from Atlassian for Customers:

https://confluence.atlassian.com/kb/faq-for-cve-2021-44228-1103069406.html

Official response from Atlassian for Developers:

https://community.developer.atlassian.com/t/update-atlassians-investigation-on-cve-2021-44228/54352

Jira

It looks like Jira itself isn’t compromised because modern versions come with a log4j version that is too old to be impacted. See above Atlassian response.

There is some speculation that the existing CVE is NOT broad enough, and Jira’s version may be impacted: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126

This seems to have been refuted by one of the original authors of log4j 1.x at https://twitter.com/ceki/status/1469449618316533762

Confluence

We have not looked at Confluence as of yet. See above Atlassian response.

Third Party Apps

We believe there is a generalized process for identifying impacted third party apps. It follows steps along the lines of:

cd /YOUR PATH/jira-home-shared/plugins/installed-plugins/
mkdir log4shell
cp *.jar log4shell/
cd log4shell/
cat rename.sh
  for f in *.jar; do
    mv -- "$f" "${f%.jar}.zip"
  done
./rename.sh
find . -name '*.zip' -exec sh -c 'unzip -d "${1%.*}" "$1"' _ {} \;
find ./ -name *log4j* | grep -v log4j.properties | grep jar

If you see entries that end in .jar then there is cause to be concerned. Then compare the log4j version that matches the CVE (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228) – Log4j2 <=2.14.1

Based on the new FAQ linked above, you can also try running this command to see if any apps are impacted:

grep -r org.apache.log4j.net.JMSAppender *

Developers

See the official announcement from Atlassian above.

Also, you can see an example of this compromise at https://github.com/christophetd/log4shell-vulnerable-app

Possible Mitigation

According to https://www.zdnet.com/article/security-warning-new-zero-day-in-the-log4j-java-library-is-already-being-exploited/ it looks like you can mitigate the issue using a JVM flag of “-Dlog4j2.formatMsgNoLookups=true” however we have not verified this as of yet.

One customer has reported that this mitigation with Jira Data Center 8.13.13 did not seem to cause any harm on being applied. We don’t have confirmation as of yet if it actually mitigated the underlying issue or not.

Detection

A number of abuse detection mechanisms are being compiled by various community members at https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b

Have questions?

Atlas Authority is a full-service consulting firm, ready to help you get the most out of your technology.

Stay fresh

Sign up to receive our monthly newsletter, featuring the latest blog posts.

Related Blog Posts

Jira and monday.com Integrations FAQ

Jira and monday.com Integrations FAQ

Many organizations are figuring out how Jira and monday.com can work together to enable effective collaboration. We answer a few basic questions to help you get started.

Lessons Learned From Jira Admin Confessions

Lessons Learned From Jira Admin Confessions

Lessons Learned From Jira Admin ConfessionsWe’re just going to address the elephant in the room and say that we know that everyone is thinking about migrations as of late. You have probably already had several conversations with colleagues and co-workers about what’s...

Share This