Is Confluence Data Center server vulnerable to CVE-2021-44228

[metizik]

We use Confluence DC and I would like to know if its log4j implementation is vulnerable to https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228 ?

[Stefan Pinter]

hi!

we use Confluence v7.13.0 and Jira v8.20.0...

are we safe? what can we do? this seems to be very urgent!

[Tamas Bela]

No. You are not safe. But not for what you thought so.

Multiple Products Security Advisory - Unrendered unicode bidirectional override characters - CVE-2021-42574 | Atlassian Support | Atlassian Documentation

[Jens Kisters __SeibertSolutions]

If Atlassian has already created issues for this on jira.atlassian.com they seem still to be private:

https://jira.atlassian.com/issues/?jql=labels%20%3D%20CVE-2021-44228

[Jens Kisters __SeibertSolutions]

IMHO if you search long enough i think youd find a REST or something that is accessible from the public and that passes on a input parameter to the log :(

[Nordix Infra]

Hi, 

It will be good to know what is Atlassian standing on this issue.

[Benutzer Support GASCADE]

It seems Atlassian uses log4j 1.2.17 and log4j 1.x is not affected... Maybe anyone of Atlassian can confirm that?

[Jens Kisters __SeibertSolutions]

great hint! i love it when the internet works

[Tom Mason]

Be sure to read the part about JMS Appender

[Nordix Infra]

I'm using Confluence 7.13.0 and this is using log4j 1.x which is NOT vulnerable.

Please refer: https://access.redhat.com/security/cve/cve-2021-44228

/var/atlassian/application-data/confluence# find / -name log4j\*
/opt/atlassian/confluence/confluence/WEB-INF/lib/log4j-1.2.17-atlassian-3.jar
/opt/atlassian/confluence/confluence/WEB-INF/lib/log4j2-stacktrace-origins-2.2-atlassian-2.jar
/opt/atlassian/confluence/confluence/WEB-INF/lib/log4j12-extras-0.0.2.jar

[INSOnline]

what about this: /opt/atlassian/confluence/confluence/WEB-INF/lib/log4j2-stacktrace-origins-2.2-atlassian-2.jar ?

[Beau P.]

@Nordix Infra Redhat updated that page to say that 1.x MAY be vulnerable. Earlier it said 1.x was no vulnerable. Just FYI.

[Alissa Mamon]

Due to the existence of JMS Appender which can use JNDI in the log4j 1.x, it is possible that log4j version 1.x is also affected by this vulnerability. The impact is still under investigation.

[UCAR Webmaster]

Some minimal discussion here:

https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126

[Sune Mølgaard]

Local test also employing https://github.com/welk1n/JNDI-Injection-Exploit and confirmed working with regular PoC Java code:

The following in Scriptrunner would have logged

Reference Class Name: foo

if vulnerable, but instead, I got

2021-12-10 16:18:27,409+0100 http-nio-8380-exec-18 ERROR smo 978x121137x1 34zr5s 188.180.77.76,127.0.0.1 /rest/scriptrunner/latest/user/exec/ [c.o.scriptrunner.runner.AbstractScriptRunner] jndi:ldap://127.0.0.1:1389/Basic/Command/Base64/dG91Y2ggL3RtcC8xMjM 

 Scriptrunner code:

import org.apache.log4j.LogManager;
import org.apache.log4j.Logger;

String str = "jndi:ldap://127.0.0.1:1389/Basic/Command/Base64/dG91Y2ggL3RtcC8xMjM";
log.error("${str}");

So it seems, at least to me, that Log4j, in the 1.x versions used by Atlassian applications, are not vulnerable.

[Bryan Guffey]

Hey you tested JIra? 

[Matt Joyce]

Using container version: 
atlassian/jira-software   tag   latest   as of 13 days ago

In /opt/atlassian pathes I see log4j as being this version:

./jira/lib/log4j-1.2.17-atlassian-3.jar

 So assuming that that is correct, and no other plugin is making use of another statically loaded log4j, or you don't have some other integration piece you've built or polluted your jdk with... it SHOULD be safe.

That being said... if you are piping logs to a log aggregator like ELK.  ELK may not be safe.  Some folks have successfully PoC'ed the exploit on ELK configurations.  So context matters a great deal.

But I am not atlassian.  I too hope atlassian chimes in with an official response.   

[Matt Joyce]

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

[Terry Moberley]

We do not allow any access to Jira from outside our Firewall.  We only use it internally, so we are safe.  Check out the article Nordix posted above.  Simple to understand.

[Andreas]

Just as a reminder, lot of attacks come from inside, even if you run an internal System, security issues should be patched. The firewall does not make it safe - it makes it just a bit harder to attack 

[Terry Moberley]

I don't believe there is a patch for this yet, correct?

[Mayuresh Sakharape]

@Terry Moberley There is not and Atlassian believe they dont need one as well. They have updated the announcement page. Please check. https://confluence.atlassian.com/kb/faq-for-cve-2021-44228-1103069406.html

[Ramiro Encinas]

There is a jar (\Atlassian\Confluence\confluence\WEB-INF\lib\log4j2-stacktrace-origins-2.2-atlassian-2.jar) that apparently refers to the version 2.x

[Daniel Eads]

Hi all,

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

[Kelly Phillips]

Hi

Is there a later update?

[Mayuresh Sakharape]

Hi @Daniel Eads ,

Could you please let us know which log4j version is used in jira and confluence.

We see 2 log4j related jars

install_directory/lib/log4j-1.2.17-atlassian-2.jar

install_directory/atlassian-jira/WEB-INF/lib/log4j2-stacktrace-origins-2.2-atlassian-2.jar

Its interesting to know the use of both.

Kind Regards,

Mayuresh

[Maurice H.]

Check https://confluence.atlassian.com/kb/faq-for-cve-2021-44228-1103069406.html for latest answers to this topic.

[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.

Additionally there is more information available 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

[Andreas]

Thank you for sharing and posting the official statement 👍🏻

[andrewbrock]

Still no mention of elasticsearch that's bundled with BitBucket though?

[Tom Mason]

Their stance on elasticsearch is that you should deal with Elastic Search and not Atlassian.  I feel like that is an incorrect position to take, especially for the bundled version that they install.

They did end up helping us.  We added this line:

-Dlog4j2.formatMsgNoLookups=true

to

$BITBUCKET_HOME/shared/search/jvm.options

[Daniel Eads]

Hi all,

Daniel from Atlassian Support - I'd like to let you know that we have updated the advisory to include more information about Bitbucket Server, Bitbucket Data Center, and the bundled elasticsearch product. Please refer to the advisory for the most current guidance:

• https://confluence.atlassian.com/security/multiple-products-security-advisory-log4j-vulnerable-to-remote-code-execution-cve-2021-44228-1103069934.html 

Thanks,
Daniel Eads | Atlassian Support 

[Jayachandran Palanisamy]

I have found the following information from our Atlassian Confluence DC v.7.13.0. Do I need worry?

# grype /opt/atlassian/confluence/temp/4.0.0-master-f680ea21.jar
✔ Vulnerability DB [no update available]
New version of grype is available: 0.27.1
✔ Indexed /opt/atlassian/confluence/temp/4.0.0-master-f680ea21.jar
✔ Cataloged packages [97 packages]
✔ Scanned image [16 vulnerabilities]
NAME INSTALLED FIXED-IN VULNERABILITY SEVERITY
commons-compress 1.20 1.21 GHSA-7hfm-57qf-j43q High
commons-compress 1.20 1.21 GHSA-crv7-7245-f45f High
commons-compress 1.20 1.21 GHSA-mc84-pj99-q6hh High
commons-compress 1.20 1.21 GHSA-xqfj-vm6h-2x34 High
commons-compress 1.20 CVE-2021-35515 High
commons-compress 1.20 CVE-2021-35516 High
commons-compress 1.20 CVE-2021-35517 High
commons-compress 1.20 CVE-2021-36090 High
jsoup 1.9.2 1.14.2 GHSA-m72m-mhq2-9p6c High
jsoup 1.9.2 CVE-2021-37714 High
log4j 1.2.17-atlassian-3 GHSA-2qrg-x229-3v8q Critical
log4j 1.2.17-atlassian-3 CVE-2019-17571 Critical
log4j 1.2.17-atlassian-3 CVE-2020-9488 Low
netty-codec 4.1.65.Final 4.1.68.Final GHSA-grg4-wf29-r9vv Medium
netty-codec 4.1.65.Final 4.1.68.Final GHSA-9vjp-v76f-g363 Medium
netty-codec-http 4.1.65.Final 4.1.71.Final GHSA-wx5j-54mm-rqqq Medium

Regards,
Jay

[Jayachandran Palanisamy]

I hope the team checked this vulnerability as well.
https://nvd.nist.gov/vuln/detail/CVE-2021-45046

Please confirm.

/Jay