My IT security team keep flagging bitbucket server (well its elasticsearch service) as a threat due to the log4j vulnerability.
I upgraded to the lastest 7.19.3 which I thought from the release notes was deploying the "safe" 2.16 version but it turns out that I can still see 2.11.
Please provide a clear walk through on how to remove these files (which I believed are not used for logging by Bitbucket) and/or upgrade to 2.16.
I ended up applying the solution provided by @Radek Janata on
Log4J vulnerability (atlassian.com)
of removing the offending class from the *.jar file.
Hey @Ben238
I was just going through some FQA's pulled out from this link https://confluence.atlassian.com/kb/faq-for-cve-2021-44228-1103069406.html
I see Bitbucket Server/Data Center isn't in the list of products using Log4j but I can see Log4j JAR files in my installation directory, is my instance vulnerable?
Neither Bitbucket Server nor Data Center use Log4j, they use Logback. The files exist to allow Log4j components to be used for the logging framework which isn't vulnerable.
We have updated our security advisory on 16 Dec 2021 to highlight that Bitbucket Server and Data Center are vulnerable due to usage of Elasticsearch which is bundled with Bitbucket. Learn more about upgrading to a fixed version and how to mitigate the vulnerability in the interim in the advisory: Multiple Products Security Advisory - Log4j Vulnerable To Remote Code Execution - CVE-2021-44228
Still referring to Bitbucket Server/Data Center, should I delete the JAR files?
No, do not delete the JAR files. While deleting the JARs won't impact core Bitbucket functionality, other apps may be impacted, including apps in the Atlassian ecosystem. The apps that use our Log4j's APIs (v1 or v2) in product actually log with Logback.
Hope this helps !!, let me know in case of any questions.
Having said these, where did you see in release notes that there was upgraded log4j ?
Regards,
Vishwas
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Vishwas N M ,
Thank you for coming back to me.
I believe the workaround
-Dlog4j2.formatMsgNoLookups=true
has no been discredited and should be ignored.
I ended up applying the solution provided by @Radek Janata on
Log4J vulnerability (atlassian.com)
of removing the offending class from the *.jar file.
First time I let my IT department do it and ended up with a crippled BitBucket but I re-installed it anew and when I did it myself, it worked a treat.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.