Is log4j2-stacktrace-origins-2.2-atlassian-2.jar vulnerable to CVE-2021-44228?

[Ramiro Encinas]

Is the only jar file:

\Atlassian\JIRA\atlassian-jira\WEB-INF\lib\log4j2-stacktrace-origins-2.2-atlassian-2.jar

that CVE-2021-44228 refers as affected version.

[Daniel Eads · Accepted solution]

Hi @Ramiro Encinas ,

Daniel from Atlassian Support here. I'd just like to provide you with this preliminary FAQ related to the log4j zero-day. Our Security team is currently investigating the impact of the Log4j remote code execution vulnerability (CVE-2021-44228) and determining any possible impacts. In the meantime, hopefully this FAQ will help address some initial questions you may have.

Thanks,
Daniel Eads | Atlassian Support

[Jun]

Hi @Daniel Eads ,

I read the FAQ for CVE-2021-44228, thanks.

I have checked the log4j2-stacktrace-origins-2.2-atlassian-2.jar.
I checked the mvnrepository and found that the log4j2-stacktrace-origins package has only version 2.2-atlassian-2 available in Atlassian.

https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j2-stacktrace-origins 

Looking at the Bitbucket repository, which seems to be the source code of the package, this code is described as the code that cut out the stack trace part from log4j 2.x.
Therefore, this log4j2-stacktrace-origins-2.2-atlassian-2.jar is considered to be a copy of the code from a place unrelated to this vulnerability, so we thought there was no vulnerability issue.

Would you please give us your opinion?

Thanks,

[Productivity Standards and Practices]

Our security team told us that for those who have a java application with these modules:

log4j-api-2.10.0.jar to log4j-api-2.14.x.jar
log4j-core-2.10.0.jar to log4j-core-2.14.x.jar

and that cannot be upgraded to latest log4j fixed version,  they can mitigate the vulnerability by adding this to their application's java parameters: 

-Dlog4j2.formatMsgNoLookups=true

Can someone from Atlassian confirm this?

[Daniel Eads]

Hi all,

Daniel with Atlassian Support here to let you know our security team has finished its investigation. We have an official response statement here on Community, which you can access at this link.

More information can be found on our advisory page, as well as the previously-published FAQ:

• https://confluence.atlassian.com/display/SECURITY/Multiple+Products+Security+Advisory+-+Log4j+Vulnerable+To+Remote+Code+Execution+-+CVE-2021-44228
• https://confluence.atlassian.com/kb/faq-for-cve-2021-44228-1103069406.html

Thanks,
Daniel Eads | Atlassian Support

[Ales Jan]

Hi Daniel,

I have checked all the provided links, but there is no answer according to the question.
On our Jira and Conf (besides the log4j-1.2.17-atlassian-3.jar) server we also have log4j2-stacktrace-origins-2.2-atlassian-2.jar:

• <jira-install-dir>/atlassian-jira/WEB-INF/lib/log4j2-stacktrace-origins-2.2-atlassian-2.jar
• <conf-install-dir>atlassian/confluence/confluence/WEB-INF/lib/log4j2-stacktrace-origins-2.2-atlassian-2.jar

Is this a vulnerability problem?

Thanks,
Ales

[Daniel Eads]

Regarding log4j2-stacktrace-origins-2.2-atlassian-2.jar - this library is a highly cut down version of log4j 2.x that has just the stacktrace packaging code and nothing else. This results in the requirements for the vulnerability not being met.

If you wish to verify this on your own, you can expand the .jar and check for the presence of JndiLookup.class (it's not in this file). Apache's advisory mentions this in its mitigation section.

[jy]

will like to check if there is update to log4j version 2.17.1 in the road map.