SonarQube, SonarCloud, and the Log4J vulnerability

ganncamp · December 10, 2021, 5:30pm

Update 21 December 2021
Hi all,

We’ve just released SonarQube 8.9.6 LTS and 9.2.4 (Latest) to eliminate confusion and avoid false-positive from vulnerability scanning tools in regards to: CVE-2021-45046, CVE-2021-44228 and CVE-2021-45105.

In these new versions, the Elasticsearch component is updated to its latest bugfix version, 7.16.2, which updates the packaged Log4J dependency to 2.17.

Note: Although our security researchers have not found the previous SonarQube LTS (8.9.3, 8.9.4 or 8.9.5) or Latest (9.2.1,9.2.2 or 9.2.3) to be susceptible to any of the CVE’s in relation to Log4j at this time, this update has been done from an abundance of caution and we invite you to update to the latest version.

Andrea

Update 16 December 2021
Hi all,

We’ve just released SonarQube 8.9.5 LTS and 9.2.3 (Latest) to address CVE-2021-45046. In these new versions:

The SonarQube Log4J test dependency is updated to 2.16. This dependency is not used outside of unit testing, nor is it included in the SonarQube distribution. It is not susceptible to the CVEs being reported. Nonetheless, we have upgraded it to eliminate confusion.
The Elasticsearch component is updated to its latest bug fix version, 7.16.1, which removes the potentially problematic components of Log4J. Additionally, it should be noted that SonarQube programmatically adds the log4j2.formatMsgNoLookups=true JVM property on starting up Elasticsearch.
More explanations from Elasticsearch here.

Note that the LTS and the Latest are the only two supported versions. All other versions are past EOL. Please update to one of the two supported versions as soon as you can.

Ann

Update 15 December 2021
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=true JVM 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

Update 14 December 2021
Hi all,

As stated earlier, current supported versions of SonarQube are not vulnerable to this attack. Nonetheless, out of an abundance of caution and to alleviate fears, we’ve released updates to the Latest and the LTS that update Log4J to a non-vulnerable version and that add the JVM property by default.

Please see the official announcement for details: SonarQube 8.9.4 LTS and 9.2.2 released

If you have any concerns, you should upgrade to the newly-released 8.9.4 LTS or 9.2.2 (latest) immediately. No other versions are supported, and as such have not been examined w/r/t the Log4J vulnerability.

We will not be releasing Log4J patches to any other versions, nor will we be examining/testing other versions for vulnerability to the Log4J exploit. Thus, we cannot answer your questions about other versions. If you’re worried, you should upgrade to a supported version immediately.

Ann

Update 13.12.2021 We can also confirm that SonarCloud was not directly susceptible to this vulnerability, but out of an abundance of caution we have deployed a new version of SonarCloud that updates Log4J to a non-vulnerable version.

Colin

Original statement 10 December 2021
Hi all,

Concerning the reported Log4J vulnerability (CVE-2021-44228), we can confirm that the SonarQube application itself does not rely on Log4J directly and that SonarQube LTS 8.9.x and SonarQube 9.2.1 are not directly susceptible to this vulnerability.

SonarQube includes a component from ElasticSearch that contains a Log4J component. At this time, we cannot affirm that there is no risk from this component. We recommend that you add the following property in sonar.properties or through an environment variable and then restart your SonarQube instance. This will effectively mitigate any risk there might be:

sonar.search.javaAdditionalOpts=-Dlog4j2.formatMsgNoLookups=true

We are monitoring the situation and will provide a fix - if one is necessary - once it is available.

Ann

Alexandre_Gigleux · December 14, 2021, 7:56pm

A post was split to a new topic: Rule to detect vulnerable use of Log4J library?

Mathy_Scott · December 10, 2021, 6:02pm

I don’t think that the version of log4j passed to ElasticSearch (2.8.2) supports the property you recommend as a mitigation method as it seems it was introduced in 2.10.0.

ganncamp · December 10, 2021, 6:23pm

Hi @Mathy_Scott,

Welcome to the community!

You’ve picked a great one to get started on.

We run Elasticsearch with vendor-provided libraries - we don’t “pass” any dependencies - and we have confirmed that the fix we’ve provided will work.

Ann

Mathy_Scott · December 10, 2021, 6:24pm

Awesome. Thank you for the clarification.

restfulhead · December 10, 2021, 8:48pm

@ganncamp Thanks for the clarification. I believe the property in your message is not correct. It should be -Dlog4j2.formatMsgNoLookups=true (log4j2, not log4j). I suggest you update your message, so that ppl don’t copy and configure the wrong property.

Thomas_Chauchefoin · December 10, 2021, 10:49pm

@restfulhead Our tests confirmed that both settings are aliases and effectively mitigate CVE-2021-44228 on Elasticsearch. I have updated the original message with your suggestion to stick to the official security advisory and avoid any further confusion. Thank you for the heads-up!

colin_expeto · December 11, 2021, 1:48am

What if we are using the official SonarQube docker container? Is there an easy way to pass in extra java options?

Thomas_Chauchefoin · December 11, 2021, 2:44am

@colin_expeto The same mitigation can be applied. You can use the environment variable SONAR_SEARCH_JAVAADDITIONALOPTS to pass JVM options to the Elasticsearch instance:

$ docker run -p 9000:9000 -e SONAR_SEARCH_JAVAADDITIONALOPTS=-Dlog4j2.formatMsgNoLookups=true sonarqube:latest
[...]
2021.12.11 02:32:59 INFO  es[][o.e.n.Node] JVM arguments [[...] -Dlog4j2.formatMsgNoLookups=true [...]]

danhersh · December 11, 2021, 6:48pm

Thanks. What about earlier versions? We are on 6.7.2 and recently 7.9.3. Do we need the fix and if so will it be the same fix?

umapathy · December 12, 2021, 12:15am

@ganncamp Would this fix work on SonarQube 7.9.2 version ?

jjj · December 12, 2021, 8:09am

I have a question in the other direction: Presumably Log4J itself has been analyzed using SonarQube (*), and in principle SonarQube can find deserialization vulnerabilities (which I think this is ? (**)).

What was missing which kept SonarQube from finding this vulnerability in Log4J and how can SonarQube be improved to find these kind of vulnerabilities in the future ?

(*) https://sonarcloud.io/explore/projects?search=log4j
(**) Apache log4j Vulnerability CVE-2021-4428: Analysis and Mitigations

Li_Dai · December 13, 2021, 1:02am

Is Sonarqube 6.3.1 affected by this Log4J vulnerability?

ChristianK · December 13, 2021, 9:25am

Similar questions to SonarQube Server 7.9.1.27448, is this version affected by this vulnerability?

According to trivy following versions are being used in 7.9.1.27448:
org.apache.logging.log4j:log4j-api

2.11.1
2.8.2
org.apache.logging.log4j:log4j-core
2.11.1

bms-lgpn · December 13, 2021, 9:50am

Hello, I have SonarQube 8.8.0. I applied the advised configuration. When I look for java processes in my machine, I can see the new java parameter -Dlog4j2.formatMsgNoLookups=true in this process:

sonarqu+  7752  5.2  2.8 6086756 458696 ?      Sl   09:22   0:49 /usr/lib/jvm/java-11-openjdk-amd64/bin/java -Djava.awt.headless=true -Dfile.encoding=UTF-8 -Djava.io.tmpdir=/opt/sonarqube/temp -XX:-OmitStackTraceInFastThrow --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.io=ALL-UNNAMED --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED -Xmx512m -Xms128m -XX:+HeapDumpOnOutOfMemoryError -Dlog4j2.formatMsgNoLookups=true -Dhttp.nonProxyHosts=localhost|127.*|[::1] -cp ./lib/common/*:/opt/sonarqube/sonarqube-8.8.0.42792/lib/jdbc/postgresql/postgresql-42.2.19.jar org.sonar.server.app.WebServer /opt/sonarqube/temp/sq-process17321630725073404588properties

But not in the “elasticsearch” one:

sonarqu+  7592  3.4  5.0 6344308 805864 ?      Sl   09:21   0:32 /usr/lib/jvm/java-11-openjdk-amd64/bin/java -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -Djava.io.tmpdir=/opt/sonarqube/temp -XX:ErrorFile=../logs/es_hs_err_pid%p.log -Des.networkaddress.cache.ttl=60 -Des.networkaddress.cache.negative.ttl=10 -XX:+AlwaysPreTouch -Xss1m -Djava.awt.headless=true -Dfile.encoding=UTF-8 -Djna.nosys=true -XX:-OmitStackTraceInFastThrow -Dio.netty.noUnsafe=true -Dio.netty.noKeySetOptimization=true -Dio.netty.recycler.maxCapacityPerThread=0 -Dio.netty.allocator.numDirectArenas=0 -Dlog4j.shutdownHookEnabled=false -Dlog4j2.disable.jmx=true -Djava.locale.providers=COMPAT -Des.enforce.bootstrap.checks=true -Xmx512m -Xms512m -XX:MaxDirectMemorySize=256m -XX:+HeapDumpOnOutOfMemoryError -Des.path.home=/opt/sonarqube/sonarqube-8.8.0.42792/elasticsearch -Des.path.conf=/opt/sonarqube/temp/conf/es -Des.distribution.flavor=default -Des.distribution.type=tar -Des.bundled_jdk=false -cp /opt/sonarqube/sonarqube-8.8.0.42792/elasticsearch/lib/* org.elasticsearch.bootstrap.Elasticsearch

Is it normal?

EDIT 13/12/2021: I modified the wrong config parameter ( sonar.web.javaAdditionalOpts instead of sonar.search.javaAdditionalOpts). It works as expected now.

mhow2 · December 13, 2021, 10:11am

It doesn’t look normal to me, at least I’m observing the contrary behavior: The process with postgresql don’t have it but the one with elastic have.

Did you double check that you added the value to sonar.search.javaAdditionalOpts ?

bms-lgpn · December 13, 2021, 10:21am

Thanks for your reply. It was my mistake. I read too fast the sonarqube parameter in sonar.properties and changed the wrong one (sonar.web.javaAdditionalOpts instead of sonar.search.javaAdditionalOpts).

jackpriceburns · December 13, 2021, 12:00pm

I’m running the SonarQube community container from DockerHub.

I already have sonar.search.javaAdditionalOpts set to fix a bug with something else
-Dsonar.search.javaAdditionalOpts=-Dnode.store.allow_mmap=false
what is the syntax for adding this additional argument?

Can I do
-Dsonar.search.javaAdditionalOpts=-Dnode.store.allow_mmap=false,-Dlog4j2.formatMsgNoLookups=true
for example?

Or can I set it twice?
-Dsonar.search.javaAdditionalOpts=-Dnode.store.allow_mmap=false AND
-Dsonar.search.javaAdditionalOpts=-Dlog4j2.formatMsgNoLookups=true ?

Vincent_Klock · December 13, 2021, 12:27pm

Hi, same question here: we are currently using 7.9.1, we are in the process of jumping to v8 but we aren’t ready yet for this.

ganncamp · December 13, 2021, 12:47pm

Hi all,

Our version support is spelled out here, in case you have not read it recently. So we can only speak to 8.9.3, the current LTS, and 9.2.1, the latest version, since they are the only supported versions. If you are on an older version we strongly recommend you upgrade.

Ann