SonarQube, SonarCloud, and the Log4J vulnerability

[ganncamp (G Ann Campbell)]

Hi,

From CVE-2021-44832 (emphasis mine):

Apache Log4j2 versions 2.0-beta7 through 2.17.0… are vulnerable to a remote code execution (RCE) attack when a configuration uses a JDBC Appender with a JNDI LDAP data source URI when an attacker has control of the target LDAP server. This issue is fixed by limiting JNDI data source names to the java protocol in Log4j2 versions 2.17.1, 2.12.4, and 2.3.2.

 
HTH,
Ann

[mtarnawa (Mateusz Tarnawa)]

Hello Ann,

As you pointed out in the excerpt from the CVE report the issue is fixed in 2.17.1. Latest Sonarqube LTS 8.9.9 is running 2.17.0. Are there any plans to update the Elasticsearch version to the one that’s using >= 2.17.1? Should this be still sent to security@sonarsource.com or is there any other authoritative way to submit a feature request?

Thanks,
Mateusz

[Chris (Christophe Lévis)]

Hi @Mateusz,

As already explained in this thread, Elasticsearch was updated in SonarQube 9.3 (SONAR-15869) to avoid false positives from security tools regarding CVE-2021-44832. There’s no plan to update Elasticsearch in the 8.9.x LTS for this topic.
You’ll find the explanation here:

SonarQube, SonarCloud, and the Log4J vulnerability

Hi Rukesh, To be clear, our security researchers have found no way to exploit the Log4J vulnerabilities in any of the 8.9 point versions. The latest releases of SonarQube - including the LTS - don’t use Log4J directly. The embedded Elasticsearch does contain Log4J but there is no vulnerability in the way Elasticsearch uses it. So we do not plan to upgrade Elasticsearch in the LTS.   HTH, Ann

Chris

[mtarnawa (Mateusz Tarnawa)]

Hi Chris (can’t at-mention you unfortunately)

There’s no plan to update Elasticsearch in the 8.9.x LTS for this topic.

Thank you, a statement like that was pretty much what I was looking for.