SonarQube, SonarCloud, and the Log4J vulnerability

Concerning version 7.9, is it impacted ?
As i can see the addition of the parameter sonar.search.javaAdditionalOpts=-Dlog4j2.formatMsgNoLookups=true is not good enough to mitigate the vulnerability.
Thanks alot for the follow-up

1 Like

@ganncamp, merely noting SonarSource only support the latest LTS and regular release and deflecting any questions is not going to win many karma points, when you’ve already invalidated the releases that were in place when this was announced last week. Not everyone, especially your paying Enterprise customers with strict change control procedures can’t just jump to the latest release,even for a zero-day!

For those who can’t upgrade to the latest and since "the situation is evolving and new findings are coming out ", we already know the log4j2.formatMsgNoLookups=true will not eliminate the issue, hence log4j-2.16.0 (See - Older (discredited) mitigation measures ).

Further, as long as the embedded Elastic Search component also packages log4j2 < 2.16.0, people will be concerned.

Historically, we can see:

sonarqube-5.6.7.zip
	sonarqube-5.6.7/lib/common/elasticsearch-1.7.5.jar
	sonarqube-5.6.7/lib/server/log4j-over-slf4j-1.7.12.jar

sonarqube-6.7.7.zip
	sonarqube-6.7.7/lib/common/log4j-api-2.8.2.jar
	sonarqube-6.7.7/lib/common/log4j-core-2.8.2.jar
	sonarqube-6.7.7/lib/common/log4j-to-slf4j-2.8.2.jar
	sonarqube-6.7.7/lib/server/log4j-over-slf4j-1.7.25.jar
	sonarqube-6.7.7/elasticsearch/lib/elasticsearch-5.6.3.jar
	sonarqube-6.7.7/elasticsearch/lib/log4j-1.2-api-2.9.1.jar
	sonarqube-6.7.7/elasticsearch/lib/log4j-api-2.9.1.jar
	sonarqube-6.7.7/elasticsearch/lib/log4j-core-2.9.1.jar

sonarqube-7.9.6.zip
	sonarqube-7.9.6/lib/common/log4j-to-slf4j-2.8.2.jar
	sonarqube-7.9.6/elasticsearch/lib/elasticsearch-6.8.0.jar
	sonarqube-7.9.6/elasticsearch/lib/log4j-1.2-api-2.11.1.jar
	sonarqube-7.9.6/elasticsearch/lib/log4j-api-2.11.1.jar
	sonarqube-7.9.6/elasticsearch/lib/log4j-core-2.11.1.jar

sonarqube-8.9.4.50575.zip
   sonarqube-8.9.4.50575/elasticsearch/lib/elasticsearch-7.13.4.jar
   sonarqube-8.9.4.50575/elasticsearch/lib/log4j-core-2.11.1.jar
   sonarqube-8.9.4.50575/elasticsearch/lib/log4j-api-2.11.1.jar

So versions prior to 6.x are not vulnerable.
6.x appears to use log4j-over-slf4j (but include core) and ES uses log4j-core.
7.x use log4j-over-slf4j and ES uses log4j-core.
8.x only has ES, which uses log4j-core.

Can SonarSource confirm SonarQube used slf4j logging and does not use / is not aware of the application using the JndiLookup feature directly (we can assume ES components are vulnerable but not using jndiLookup) ?

And confirm there will be no impact to any version of SonarQube if customers apply Apache’s fallback guidance to remove the class : zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class ?

This mitigating action would be prudent for all users, even those using the SonarSource supported versions, as long as log4j2 < 2.16.0 is present. What was the first SonarQube release to use Log4j2 ?

We all eagerly anticipate a new SonarQube release, embedding Elasticsearch 7.16.1+, in which they have declared the first CVE-2021-44228 mitigated. Hopefully, they quickly address the second CVE-2021-45046 quickly as well as you can release an update for that too.

3 Likes

I have been checking Elastic.co’s forum post on this issue at Apache Log4j2 Remote Code Execution (RCE) Vulnerability - CVE-2021-44228 - ESA-2021-31 - Security Announcements - Discuss the Elastic Stack
In it they wrote

Supported versions of Elasticsearch (6.8.9+, 7.8+) used with recent versions of the JDK (JDK9+) are not susceptible to either remote code execution or information leakage. This is due to Elasticsearch’s usage of the Java Security Manager. Most other versions (5.6.11+, 6.4.0+ and 7.0.0+) can be protected via a simple JVM property change. The information leak vulnerability does not permit access to data within the Elasticsearch cluster. We have released Elasticsearch 7.16.1 and 6.8.21 which contain the JVM property by default and remove certain components of Log4j out of an abundance of caution. This is applicable to both CVE-2021-44228 and CVE-2021-45046.

and

[Update 15 December] A further vulnerability (CVE-2021-45046) was disclosed on December 14th after it was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. Our guidance for Elasticsearch, APM Java Agent, and Logstash are unchanged by this new vulnerability.

On one side, I’m sure elastic knows their own codebase and they must have done due diligence to check whether they are vulnerable or not. On the other hand, I would feel more reassured if this was confirmed by a second opinion coming from an independent security researcher or something along that line.
The fact that vulnerability check tools mark the log4j library in the sonarqube stack with a red flag is concerning, especially when I think of how how much effort will corporate GSO put into investigating the issue case by case and relying on forum post statements instead of just deferring to the suggestion of whatever scanner they use and shut down anything that has the vulnerable library.
Due to this, I’m leaning towards deleting the affected library from the server. It might break sonarqube, but I’m afraid the whole server might get shut down by some heavy-handed approach by the head office in the coming days anyways.

3 Likes

any reason for not recommending the fallback logic as proposed by apache :

  • Otherwise, remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

https://logging.apache.org/log4j/2.x/security.html

I agree with you.
According to elastic.io statement when running SQ 8.9.3 - which has EL 7.13.4 bundled - on JDK 11, there should not be an issue. But I will also wait for more information and go on with deleting the JndiLookup class from the core library.

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

6 Likes

@ganncamp when will the helm chart and docker image updates rollout? As of ~2:40PM ET the update is still not available via Dockerhub/helm.

Thanks

1 Like

Hi @michaelgg13,

Welcome to the community! That’s a great first question.

Typically, the Docker / Helm updates lag a bit. We’ve submitted the PRs, but we’re not the approvers.

 
:woman_shrugging:
Ann

1 Like

The Docker images are avalable now. i guess the helm chart will follow tomorrow

1 Like

@DefinitelyNotTobi based on a prisma cloud scan, the 8.9.5 images that sonar shipped still have log4j 2.11.1 on them :frowning:

@ganncamp FYI on the above

1 Like

Hi,
Sorry to say this but Log4J is not upgraded with the latest LTS version (SonarQube Enterprise Edition Version 8.9.5 (build 50698)):

When can we expect a fix for this - it’s becoming quite critical ? Any instructions to follow until this is fixed ?

Hi,

only log4j-core is affected by log4shell (CVE-2021-44228) and CVE-2021-45046.
Just downloaded sonarqube-enterprise-8.9.5.50698 and sonarqube-enterprise-9.2.3.50713
The …/elasticsearch/lib/log4j-core-2.11.1.jar is removed, so all fine.

Gilbert

5 Likes

Thanks - I guess this could have been described by SonarSource in the “release notes” to remove the confusion.

Hi @michaelgg13,

The Elasticsearch folks removed the offending class and repackaged the jar. That’s why you see it renamed.

 
HTH,
Ann

4 Likes

Hin @ganncamp

We have 8.9.0 version and a lot of configurations (LDAP and GITLAB integrations).
Could you send me a link with a fast procedure to do this upgrade (from 8.9.0 to 8.9.5).
I’ve already searched this at documentation but I was confused what is necessary…

Thanks,

Hi,

according to the docs Before You Upgrade | SonarQube Docs => Migration Path
this should be straight 8.9.0 (first 8.9.x LTS version) to 8.9.5 (most recent 8.9.x LTS version).

i.e. i myself updated today from 8.9.1 to 8.9.5 without any problems.

Gilbert

5 Likes

Hi @alevenelli,

To augment Gilbert’s excellent answer, I just want to say that in this within-version situation, you should be good to just copy your configuration file from one to the other and go.

 
HTH,
Ann

1 Like

Could you explain why log4j-api-2.11.1.jar is still part of the image?

$ docker run -it --rm --entrypoint /bin/bash sonarqube:8.9.5-community
Unable to find image 'sonarqube:8.9.5-community' locally
8.9.5-community: Pulling from library/sonarqube
8572bc8fb8a3: Already exists 
702f1610d53e: Already exists 
8c951e69c28d: Already exists 
9588b35368ad: Pull complete 
66a6213f95b1: Pull complete 
Digest: sha256:7dcdbe5916baa346ce039ca67c58794e0a0d7380976cbef37725ec0cd5330455
Status: Downloaded newer image for sonarqube:8.9.5-community
bash-5.0# find /opt/sonarqube/ -name "*log4j*.jar"
/opt/sonarqube/elasticsearch/lib/elasticsearch-log4j-7.16.1.jar
/opt/sonarqube/elasticsearch/lib/log4j-api-2.11.1.jar
1 Like

Please read the previous answers. The vulnerablity only affects log4j-core (and you’re looking at log4j-api).

2 Likes

Thanks @ganncamp unfortunately, removing the class is no longer an acceptable resolution per our organization’s SOC.

We are actually an enterprise customer, I will likely go that route to voice our concerns (Enterprise Support). We are likely going to have to shutdown our Sonarqube installation until the elastic dependency can be upgraded to include log4j 2.16.0.

Regardless of whether or not the mitigations are in place, its just not worth the risk for an organization. Apologies for the directness, but I am sure other companies using Sonarqube that deal with PHI/PII/HIPAA data are in the same boat.

1 Like