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

Share This