Log4J vulnerability

Jens Rapp December 13, 2021

Hello,

hopefully, I'm right here.

Just got mentioned towards https://www.lunasec.io/docs/blog/log4j-zero-day/

our bitbucket 7.17.1 seems to use log4j 2.14.1. elasticsearch uses 2.11.1

 [git 7.17.1]$ find . -name log4j*
./app/WEB-INF/lib/log4j-api-2.14.1.jar
./app/WEB-INF/lib/log4j-core-2.14.1.jar
./app/WEB-INF/lib/log4j-over-slf4j-1.7.25.jar
./app/WEB-INF/lib/log4j-to-slf4j-2.14.1.jar
./elasticsearch/lib/log4j-api-2.11.1.jar
./elasticsearch/lib/log4j-core-2.11.1.jar
./elasticsearch/config-template/log4j2.properties
./licenses/log4j--log4j--1.2.17.txt

Any idea if there will be a fix.. and when?

4 answers

Suggest an answer

Log in or Sign up to answer
2 votes
Nicolas Esteves December 13, 2021

Atlassian says Bitbucket is not affected in their KB: https://confluence.atlassian.com/kb/faq-for-cve-2021-44228-1103069406.html

[...] if a you have modified the default logging configuration (log4j.properties) to enable the JMS Appender functionality, remote code execution may be possible in the following products (Bitbucket Server & Data Center are not affected):

  • Jira Server & Data Center

  • Confluence Server & Data Center

  • Bamboo Server & Data Center

  • Crowd Server & Data Center
  • Fisheye

  • Crucible

1 vote
pmarx December 14, 2021

I have the same issue on our internal bitbucket system with elasticsearch:

Binary file /opt/atlassian/bitbucket/7.18.0/app/WEB-INF/lib/log4j-core-2.14.1.jar matches
Binary file /opt/atlassian/bitbucket/7.18.0/elasticsearch/lib/log4j-core-2.11.1.jar matches

I have tested it with the string from https://log4shell.huntress.com/ and our firewall blocked the traffic: 

Message:
SERVER-OTHER Apache Log4j logging remote code execution attempt

Regards

Phil

0 votes
Daniel Eads
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
December 15, 2021

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:

Thanks,
Daniel Eads | Atlassian Support 

Reneesh Kottakkalathil
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
December 17, 2021

Hi Daniel,

As per this link https://www.lunasec.io/docs/blog/log4j-zero-day-update-on-cve-2021-45046/  looks like the fix in the advisory will not mitigate the risk. Can you please check?

################

Note that previous mitigations involving configuration such as to set the system property log4j2.formatMsgNoLookups to true do NOT mitigate this specific vulnerability.

##################

Daniel Eads
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
December 17, 2021

Hi @Reneesh Kottakkalathil ,

I would refer you first to the Atlassian advisory for impact on Atlassian products, and then elastic's announcement for more impact information related to the bundled elasticsearch product in Bitbucket Server. Both these articles take the information from the follow-up CVE-2021-45046 into consideration.

0 votes
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

Radek Janata December 14, 2021

@Daniel Eads, if Bitbucket does not use Log4j2, why there are the packages present? And ElasticSearch seems to use the vulnerable v2 version.

Namely, these packages contains the vulnerable JndiLookup.class:

$ grep -r --include "*.jar" JndiLookup.class /
Binary file ./7.17.1/app/WEB-INF/lib/log4j-core-2.14.1.jar matches
Binary file ./7.17.1/elasticsearch/lib/log4j-core-2.11.1.jar matches

You mention that Bitbucket doesn't use Log4j but how about bundled ElasticSearch that seem to be vulnerable?

Can you confirm that these vulnerable versions (incl. ElasticSearch) cannot affect the system from security perspective in any way (i.e. misused by an add-on/plugin)?

Shall we add the following startup parameter to ElasticSearch to be 100 % safe?

-Dlog4j2.formatMsgNoLookups=true

Or is it safe to replace the package with updated 2.15 version? Or can we safely remove the vulnerable class from the JARs using the command below? Would these operations cause anything wrong to Bitbucket or ElasticSearch (since they don't use log4j according to your official statement)?

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

 Thanks.

Like # people like this
Radek Janata December 14, 2021

Related topic on bundled ElasticSearch and its vulnerability and potential mitigation:
https://community.atlassian.com/t5/Confluence-questions/CVE-2021-44228-Atlassian-using-log4j-1-2-17/qaq-p/1884233#M227594

dylan-nicholson December 15, 2021

Thanks for that Radek - did you have any luck replacing the package with 2.15? Our IT dept is a bit paranoid and because doesn't want any copies of that current jar version on any of our systems, currently not our bitbucket/git server!  And it's definitely needed (the elasticsearch service won't start without it).

Radek Janata December 16, 2021

@dylan-nicholson, I didn't update the log4j from the system, I've just removed the vulnerable JndiLookup.class from the JAR files. The solution from Atlassian doesn't cover the newest CVE-2021-45046 vulnerability.

How to remove vulnerable class from the filesystem:

  1. stop Bitbucket
  2. run the following (it finds all files, backups them and removes the class):
    find /opt/atlassian -name "log4j-core-2.*.jar" -print -exec zip -d -q {} org/apache/logging/log4j/core/lookup/JndiLookup.class \;
  3. run Bitbucket
Like Ben238 likes this
dylan-nicholson December 16, 2021

Ok thanks, just wasn't sure if that might cause any other issues. I did confirm that the only ports elasticsearch listens on are on the loopback address (127.0.0.1) and can't be accessed externally so unless someone was able to interactively log into the bitbucket server I can't see how the vulnerability could be exploited (the only interactive login to bitbucket we allow has superuser privileges anyway so could already do whatever they liked).

TAGS
AUG Leaders

Atlassian Community Events