log4j zero-day

[Sven-Olov Lindqvist]

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

[Dave McDonnell · Accepted solution]

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]

I am on BitBucket 17.1.3 and found this helpful.

[Seth Bradford Wagenman]

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

[Five Lamb · Accepted solution]

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]

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

[Chandra M_ Bollareddy]

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?

[Daniel Eads · Accepted solution]

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

[Sven-Olov Lindqvist · Accepted solution]

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

 

[license management]

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?

[Joost Van den Cruyce · Accepted solution]

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

[gstickel]

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]

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]

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

[Chandra M_ Bollareddy · Accepted solution]

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?

[James Cregg]

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

[license management]

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?