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 ?
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!
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
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
Hi,
It will be good to know what is Atlassian standing on this issue.
It seems Atlassian uses log4j 1.2.17 and log4j 1.x is not affected... Maybe anyone of Atlassian can confirm that?
great hint! i love it when the internet works
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
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.
Hey you tested JIra?
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.
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
what about this: /opt/atlassian/confluence/confluence/WEB-INF/lib/log4j2-stacktrace-origins-2.2-atlassian-2.jar ?
@Nordix Infra Redhat updated that page to say that 1.x MAY be vulnerable. Earlier it said 1.x was no vulnerable. Just FYI.
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.
Using container version: atlassian/jira-software tag latest as of 13 days agoIn /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.
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
https://confluence.atlassian.com/kb/faq-for-cve-2021-44228-1103069406.html Official response
Hi
Is there a later update?
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
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
Check https://confluence.atlassian.com/kb/faq-for-cve-2021-44228-1103069406.html for latest answers to this topic.
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
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:
Thank you for sharing and posting the official statement 👍🏻
I don't believe there is a patch for this yet, correct?
@[deleted]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
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 SEVERITYcommons-compress 1.20 1.21 GHSA-7hfm-57qf-j43q Highcommons-compress 1.20 1.21 GHSA-crv7-7245-f45f Highcommons-compress 1.20 1.21 GHSA-mc84-pj99-q6hh Highcommons-compress 1.20 1.21 GHSA-xqfj-vm6h-2x34 Highcommons-compress 1.20 CVE-2021-35515 Highcommons-compress 1.20 CVE-2021-35516 Highcommons-compress 1.20 CVE-2021-35517 Highcommons-compress 1.20 CVE-2021-36090 Highjsoup 1.9.2 1.14.2 GHSA-m72m-mhq2-9p6c Highjsoup 1.9.2 CVE-2021-37714 Highlog4j 1.2.17-atlassian-3 GHSA-2qrg-x229-3v8q Criticallog4j 1.2.17-atlassian-3 CVE-2019-17571 Criticallog4j 1.2.17-atlassian-3 CVE-2020-9488 Lownetty-codec 4.1.65.Final 4.1.68.Final GHSA-grg4-wf29-r9vv Mediumnetty-codec 4.1.65.Final 4.1.68.Final GHSA-9vjp-v76f-g363 Mediumnetty-codec-http 4.1.65.Final 4.1.71.Final GHSA-wx5j-54mm-rqqq MediumRegards,Jay
Be sure to read the part about JMS Appender
Still no mention of elasticsearch that's bundled with BitBucket though?
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
I hope the team checked this vulnerability as well.https://nvd.nist.gov/vuln/detail/CVE-2021-45046Please confirm./Jay
It looks like you're new here. Sign in or register to get started.
