log4j zero-day

Sven-Olov Lindqvist December 10, 2021

Anyone knows if there is any impact on Atlassian Bamboo or/and Bitbucket from the node4j zero-day vulnerability.

8 answers

6 accepted

11 votes
Answer accepted
Dave McDonnell December 13, 2021

This is the response I received from Atlassian support regarding the embedded elasticsearch in Bitbucket Server (i'm running v7.17.1)

Bitbucket:

Bitbucket Server/DC does not use Log4j and is not vulnerable, however you will need to take steps to mitigate the exposure in Elasticsearch (see below)

Elasticsearch:

Per the guidance on Elastic's Website, you can protect your instance from this vulnerability by setting the below JVM option in Elasticsearch:

-Dlog4j2.formatMsgNoLookups=true

Open the file $BITBUCKET_HOME/shared/search/jvm.options. There is a block for log4j2 as following:

 
# log4j 2
-Dlog4j.shutdownHookEnabled=false
-Dlog4j2.disable.jmx=true

Include the new line -Dlog4j2.formatMsgNoLookups=true there, save the file and exit. You will need to Stop/Start Bitbucket to load the new settings.

I can see log4j .jar files in my Bitbucket installation - do I need to take action?

No. Do not delete the jar files. While deleting the jars will not impact core Bitbucket functionality, other apps (including apps in the Atlassian ecosystem) use Log4J APIs, however anything that uses Log4J's APIs (v1 or v2) in Bitbucket Server/ DC actually logs with Logback, so there is no risk and no need to take action.

Trevor Wood December 15, 2021

I am on BitBucket 17.1.3 and found this helpful.

Seth Bradford Wagenman January 6, 2022

Apparently on December 16 (the day after the most recent reply to this post), Atlassian stated that:

"Prerequisite software, Elasticsearch, used by Bitbucket Server & Data Center may be vulnerable to CVE-2021-44228"

as seen here (click "Expand" under "This advisory has been updated since the initial publication.")

Multiple Products Security Advisory - Log4j Vulnerable To Remote Code Execution - CVE-2021-44228 | Atlassian Support | Atlassian Documentation

6 votes
Answer accepted
Five Lamb
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
December 10, 2021

Hi Sven-Olov Lindqvist,

Bitbucket Server/DC does not use Log4j, and is not vulnerable to this attack.

For Bamboo, our Security team is currently investigating the impact of the Log4j remote code execution vulnerability (CVE-2021-44228) and determining any possible impacts on on-premise products.

So far, we do not believe our on-premise products are vulnerable to exploitation in their default configuration. However, if a you have modified the default logging configuration (log4j.properties) to enable the JMS Appender functionality, remote code execution may be possible.

You can check if they are vulnerable by inspecting your Log4j configuration file. If you find a line containing the org.apache.log4j.net.JMSAppender, you may be vulnerable. If you do not find a line containing the org.apache.log4j.net.JMSAppender, you do not have this specific vulnerable configuration.

We recommend that if you're using the vulnerable configuration that you mitigate the vulnerability as soon as possible by temporarily disabling any configured appenders utilizing org.apache.log4j.JMSAppender by commenting out the relevant lines in your Log4j configuration and restarting the application.

The default location of the Log4j configuration file is listed below:

Bamboo Server & Data Center

<install-directory>/atlassian-bamboo/WEB-INF/classes/log4j.properties

We have not identified any other configurations where Atlassian on-premise products are vulnerable.

Our Security team is continuing to investigate and will provide more details shortly. We will update https://confluence.atlassian.com/display/KB/FAQ+for+CVE-2021-44228 when we have new information.

Kind regards,

 

Five Lamb
Enterprise Support Engineer

Greg December 11, 2021

Regarding Bitbucket-- under 7.17.1, at least, it seems log4j core (and others) are getting pulled in.  Good to know it's not actually being used (found the Logback stuff afterwards).

user@17bc4310d361:/opt/atlassian/bitbucket/app# find `pwd` -iname '*log4j*'
/opt/atlassian/bitbucket/app/WEB-INF/lib/log4j-core-2.14.1.jar
/opt/atlassian/bitbucket/app/WEB-INF/lib/log4j-over-slf4j-1.7.25.jar
/opt/atlassian/bitbucket/app/WEB-INF/lib/log4j-api-2.14.1.jar
/opt/atlassian/bitbucket/app/WEB-INF/lib/log4j-to-slf4j-2.14.1.jar

user@17bc4310d361:/opt/atlassian/bitbucket/app# find `pwd` -iname '*logback*'
/opt/atlassian/bitbucket/app/WEB-INF/classes/com/atlassian/bitbucket/internal/boot/log/LogbackApplicationListener.class
/opt/atlassian/bitbucket/app/WEB-INF/classes/logback-spring.xml
/opt/atlassian/bitbucket/app/WEB-INF/lib/logback-classic-1.2.3.jar
/opt/atlassian/bitbucket/app/WEB-INF/lib/logback-core-1.2.3.jar
Like Dave Liao likes this
Chandra M_ Bollareddy December 12, 2021

Me to getting the below results in Bitbucket Server 7.16.0v:

/opt/atlassian/bitbucket/7.16.0/app/WEB-INF/lib/log4j-api-2.14.1.jar
/opt/atlassian/bitbucket/7.16.0/app/WEB-INF/lib/log4j-core-2.14.1.jar
/opt/atlassian/bitbucket/7.16.0/app/WEB-INF/lib/log4j-over-slf4j-1.7.25.jar
/opt/atlassian/bitbucket/7.16.0/app/WEB-INF/lib/log4j-to-slf4j-2.14.1.jar
/opt/atlassian/bitbucket/7.16.0/elasticsearch/lib/log4j-api-2.11.1.jar
/opt/atlassian/bitbucket/7.16.0/elasticsearch/lib/log4j-core-2.11.1.jar

Bamboo 8.0.0V:

/opt/atlassian/bamboo/atlassian-bamboo/WEB-INF/lib/log4j-1.2.17-atlassian-3.jar
/opt/atlassian/bamboo/atlassian-bamboo/WEB-INF/lib/log4j-api-2.9.0.jar
/opt/atlassian/bamboo/atlassian-bamboo/WEB-INF/lib/log4j-to-slf4j-2.9.0.jar
/opt/atlassian/bamboo/atlassian-bamboo/WEB-INF/lib/slf4j-log4j12-1.7.31.jar

Please suggest us..what next?

2 votes
Answer accepted
Daniel Eads
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
December 13, 2021

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:

Thanks,
Daniel Eads | Atlassian Support

2 votes
Answer accepted
Sven-Olov Lindqvist December 13, 2021

Our remote window agents seems to have log4j libraries used by the java.exe process.

log4j on Windows Remote Agent.png 

license management December 14, 2021

See similar results on linux agents:

bamboo@REDACTED:~$ find . | grep log4j | grep jar | grep -v "\.m2"
./bamboo-agent-home/classpath/slf4j-log4j12-1.7.25.jar
./bamboo-agent-home/classpath/log4j-1.2.17-atlassian-3.jar
./bamboo-agent-home/classpath/log4j-api-2.9.0.jar
./bamboo-agent-home/classpath/log4j-to-slf4j-2.9.0.jar

Do we need to worry about log4j-api/log4j-to-slf4j?

2 votes
Answer accepted
Joost Van den Cruyce December 10, 2021

already created support ticket for this, atlassian is looking into this

gstickel December 13, 2021

In our environment 7.14.1 it looks like the log4j jar files also exist. Was there a response to the support issue from Atlasssian? I am thinking that they may be used for elasticsearch but not really all that familiar.

https://discuss.elastic.co/t/apache-log4j2-remote-code-execution-rce-vulnerability-cve-2021-44228-esa-2021-31/291476

Five Lamb
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
December 13, 2021

Thanks for bringing this up. There are some mitigation steps that need to be taken if you are using BitBucket Server/DC with Elastisearch: 

Per the guidance on Elastic’s website, you can protect your instance from this vulnerability by setting the below JVM option in Elasticsearch: -Dlog4j2.formatMsgNoLookups=true

 

Kind regards,
Five Lamb
Enterprise Support Engineer

Alex Young December 13, 2021

How and where do we set this JVM option on a Windows Server please for on prem BitBucket Server with Elastic?

Like S Alexandre Lemaire likes this
0 votes
Answer accepted
Chandra M_ Bollareddy December 12, 2021

Me to getting the below results in Bitbucket Server 7.16.0v:

/opt/atlassian/bitbucket/7.16.0/app/WEB-INF/lib/log4j-api-2.14.1.jar
/opt/atlassian/bitbucket/7.16.0/app/WEB-INF/lib/log4j-core-2.14.1.jar
/opt/atlassian/bitbucket/7.16.0/app/WEB-INF/lib/log4j-over-slf4j-1.7.25.jar
/opt/atlassian/bitbucket/7.16.0/app/WEB-INF/lib/log4j-to-slf4j-2.14.1.jar
/opt/atlassian/bitbucket/7.16.0/elasticsearch/lib/log4j-api-2.11.1.jar
/opt/atlassian/bitbucket/7.16.0/elasticsearch/lib/log4j-core-2.11.1.jar

Bamboo 8.0.0V:

/opt/atlassian/bamboo/atlassian-bamboo/WEB-INF/lib/log4j-1.2.17-atlassian-3.jar
/opt/atlassian/bamboo/atlassian-bamboo/WEB-INF/lib/log4j-api-2.9.0.jar
/opt/atlassian/bamboo/atlassian-bamboo/WEB-INF/lib/log4j-to-slf4j-2.9.0.jar
/opt/atlassian/bamboo/atlassian-bamboo/WEB-INF/lib/slf4j-log4j12-1.7.31.jar

Please suggest us..what next?

0 votes
James Cregg December 14, 2021

Currently running Bamboo version 6.9 and plans to upgrade are currently on hold. Just confirming that this version is also not vulnerable to the exploit. Thanks

0 votes
license management December 14, 2021

Bitbucket DC 7.17.1 using elasticsearch for searches that indeed looks to be using a vulnerable log4j, has this vector been taken into account?

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
SERVER
TAGS
AUG Leaders

Atlassian Community Events