Log4J vulnerability

[Jens Rapp]

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?

[Nicolas Esteves]

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

[pmarx]

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

[Daniel Eads]

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:

• https://confluence.atlassian.com/security/multiple-products-security-advisory-log4j-vulnerable-to-remote-code-execution-cve-2021-44228-1103069934.html 

Thanks,
Daniel Eads | Atlassian Support 

[Reneesh Kottakkalathil]

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]

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.

[Daniel Eads]

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

[Radek Janata]

@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.

[Radek Janata]

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]

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]

@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

[dylan-nicholson]

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).