log4j zero-day
Asked by Sven-Olov Lindqvist:

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


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

### Bitbucket: {#toc-hId-1289527353}

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: {#toc-hId--517927110}

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? {#toc-hId-1969585723}

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.

comments: author: Trevor Wood
body: I am on BitBucket 17.1.3 and found this helpful.


author: Seth Bradford Wagenman
body: 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](https://confluence.atlassian.com/security/multiple-products-security-advisory-log4j-vulnerable-to-remote-code-execution-cve-2021-44228-1103069934.html#:~:text=Summary%20of%20Vulnerability%20Multiple%20Atlassian%20products%20use%20the,attacker%20controlled%20LDAP%20and%20other%20JNDI%20related%20endpoints.)**


author: Five Lamb
body: 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

comments: author: Greg
body: 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
```


author: Chandra M_ Bollareddy
body: 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?


author: Daniel Eads
body: 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.](https://community.atlassian.com/t5/Trust-Security-articles/Atlassian-s-Response-to-Log4j-CVE-2021-44228/ba-p/1886598#M134)

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


author: Sven-Olov Lindqvist
body: Our remote window agents seems to have log4j libraries used by the java.exe process.

![log4j on Windows Remote Agent.png](https://community.atlassian.com/t5/image/serverpage/image-id/173717i780821F8E3E22101/image-size/large?v=v2&px=999 "log4j on Windows Remote Agent.png")

comments: author: license management
body: 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?


author: Joost Van den Cruyce
body: already created support ticket for this, atlassian is looking into this

comments: author: gstickel
body: 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>


author: Five Lamb
body: 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](https://discuss.elastic.co/t/apache-log4j2-remote-code-execution-rce-vulnerability-cve-2021-44228-esa-2021-31/291476), 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


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


author: Chandra M_ Bollareddy
body: 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?


author: James Cregg
body: 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


author: license management
body: 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?


Tags: bitbucket

bitbucket-server

cve-2021-44228

server