I’d check that someone didn’t enable it. The standard deployment model generally means you create your own sonar.properties.
But I’m not saying that 9.2.2 doesn’t set the value, I just can’t see where its coming from in the 9.2.2-developer docker image.
My bad, you are totally correct.
I forgot that I manually modified the sonar.properties file upon installation into our custom docker container… So the mitigation settings seems to NOT be enabled at all plus it is using the still vulnerable log4j.
This logic is implemented in the code of SonarQube. It writes this setting (among others) in /opt/sonarqube/temp/conf/es/jvm.options when booting, just before starting Elasticsearch.
Yeah cool, I overwrite the settings anyway. The release notes for 8.9.4 and 9.2.2 say “SonarQube versions update Log4J to a non-vulnerable version” But that is not the case can you comment on that? This was actually the point of my original statement.
What I would like is either “i’m being dumb because…” or “Oops we made a mistake and we’ve fixed it…”
Then we can all move on to something more important. My clients would just like to have a clear statement about the state of systems so they can stop stressing.
Dear All,
I have a little bit confused,
This screenshot is from 8.9.4.50575 Community Edition:
Did you change the log4j version or just add “-Dlog4j2.formatMsgNoLookups=true” parameter?
We need to update to 2.16 or remove the class according to the CVE-2021-45046 bulletin.
Hi Ann, Could please also post how to mitigate CVE-2021-45046 NVD - CVE-2021-45046 (nist.gov) please ?
I am in the process of updating to either the latest LTS release (8.9.4.50575) or further to the latest release (9.2.2.50622), however I see both are still using log4j 2.11.1.
Could we get a confirmation whether either of these contain mitigations for the latest CVEs related to log4j?
I can see that both 8.9.4 and 9.2.2 are still using 2.11.1 for log4j in elastic search instead of 2.16.0 .However I have noticed in es log that they have added -Dlog4j2.formatMsgNoLookups=true to 8.9.4 .In earlier versions -Dlog4j2.formatMsgNoLookups=true property need to be set via sonar.properties
If I am not wrong , they have only added sonar.search.javaAdditionalOpts=-Dlog4j2.formatMsgNoLookups=true to these versions which we can see in es log. As you mentioned still old 2.11.1 jars are available with this new released version.
To completely mitigate the risk either upgrade log4j2 or remove the JndiLookup.class from the jar (https://twitter.com/jschauma/status/1470872564364980228)
Source: Log4j –
This page previously mentioned other mitigation measures, but we discovered that these measures only limit exposure while leaving some attack vectors open.
Other insufficient mitigation measures are: setting system property log4j2.formatMsgNoLookups or environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true for releases >= 2.10, or modifying the logging configuration to disable message lookups with %m{nolookups}, %msg{nolookups} or %message{nolookups} for releases >= 2.7 and <= 2.14.1.
The reason these measures are insufficient is that, in addition to the Thread Context attack vector mentioned above, there are still code paths in Log4j where message lookups could occur: known examples are applications that use Logger.printf(“%s”, userInput), or applications that use a custom message factory, where the resulting messages do not implement StringBuilderFormattable. There may be other attack vectors.
The safest thing to do is to upgrade Log4j to a safe version, or remove the JndiLookup class from the log4j-core jar.
Log4j 2.x mitigation : Implement one of the mitigation techniques below.
- Java 8 (or later) users should upgrade to release 2.16.0.
- Users requiring Java 7 should upgrade to release 2.12.2 when it becomes available (work in progress, expected to be available soon).
- Otherwise, remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability.
$zip -q -d /opt/sonarqube/elasticsearch/lib/log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
In SonarQube Community 8.9.4:
$ unzip -l /opt/sonarqube/elasticsearch/lib/log4j-core-2.11.1.jar | grep "JndiLookup.class"
07-22-2018 20:45 org/apache/logging/log4j/core/lookup/JndiLookup.class
Hi all,
SonarSource CTO Andrea Malagodi asked me to post this statement:
Hi all,
To be clear, at this time our security researchers have not found SonarQube LTS (8.9.3 or 8.9.4) or latest (9.2.1 or 9.2.2) to be susceptible to any of the CVE’s in relation to Log4j (CVE-2021-45046 and CVE-2021-44228).
Since the situation is evolving and new findings are coming out, we wanted to share an update that we hope will put to rest any concerns you may have.
In SonarQube there are two instances of Log4J:
- One is used by SonarQube’s unit tests and is not used outside of unit testing or included in the SonarQube distribution. This test dependency is not susceptible to the CVEs being reported. Nonetheless, we plan to update it.
- The other is packaged with Elasticsearch.
We are working closely with Elasticsearch and yesterday’s releases, 9.2.2 and 8.9.4 LTS, apply the mitigation they recommended at the time (
log4j2.formatMsgNoLookups=trueJVM property).Given the newly reported CVE-2021-45046, we are working to adopt Elasticsearch’s forthcoming update and issue new releases with those changes as soon as possible.
The situation is clearly still developing and we remain focused on addressing the issue as thoroughly and quickly as possible and on providing you with relevant updates as soon as we can.
Andrea Malagodi,
CTO, SonarSource
Ann
Hi Ann,
We are using SonarQube7.9.5 and I searched the word Log4j in elasticsearch folder.
I got below things:
updating “sonar.search.javaAdditionalOpts=-Dlog4j2.formatMsgNoLookups=true” will solve the issue??
I am using the HELM chart and DOCKER image to deploy sonarqube, and I am trying to change the deployment in such a way that I do not need to edit the values.yaml file. I am trying to use the --set env option as documented in the chart on github but I cannot find the correct syntax to make it work.
My latest attempt which is passed to ‘helm template’ is:
-set env.SONAR_SEARCH_JAVAADDITIONALOPTS="-Dlog4j2.formatMsgNoLookups=true" \
All of my attempts have failed with this error:
Error: YAML parse error on sonarqube/templates/deployment.yaml: error converting YAML to JSON: yaml: line 65: did not find expected key
What is the correct syntax to override that environment variable on the HELM INSTALL or HELM TEMPLATE commands?
Thanks
I also see 2.11.1 still on the 9.2.2-enterprise container image.
bash-5.1# find / -name *log4j*
/opt/sonarqube/elasticsearch/config/log4j2.properties
/opt/sonarqube/elasticsearch/lib/log4j-core-2.11.1.jar
/opt/sonarqube/elasticsearch/lib/log4j-api-2.11.1.jar
/opt/sonarqube/temp/conf/es/log4j2.properties
bash-5.1#
I’ve upgraded to sonarqube 8.9.4 using the docker image and confirmed on the web interface it is running that version.
However, if I perform an interactive login into the container and check /opt/sonarqube/conf/ and cat the file, the config option mentioned above is commented out. Should that not be set in this image?
#sonar.search.javaAdditionalOpts=
The environment variable is also not set.
So if we’ve already applied this “sonar.search.javaAdditionalOpts=-Dlog4j2.formatMsgNoLookups=true” we’re OK in regards to CVE 2021-45046?
Based on what I read here:
https://logging.apache.org/log4j/2.x/
“Note that previous mitigations involving configuration such as setting the system property log4j2.noFormatMsgLookup to true do NOT mitigate this specific vulnerability.”
I’m not clear whether this mitigates the vulnerability or not from a SonarQube perspective.
Thank you for confirming that.