Hi @byeight,
Welcome to the community!
The commented-out option does not imply that it’s already safe. It’s there, commented out, in case you need it. You’ll want to un-comment it & add the appropriate value.
HTH,
Ann
1 Like
I am running:
- SonarQube 8.9.3 LTS (which has ES 7.13.4 bundled)
- our SQ/ES is running on JDK “11.0.13”
If I understand the official statement from elastic.io correctly, is SQ 8.9.3/EL 7.13.4 running on JDK11 really affected? @ganncamp (Apache Log4j2 Remote Code Execution (RCE) Vulnerability - CVE-2021-44228 - ESA-2021-31 - Security Announcements - Discuss the Elastic Stack):
"
Elasticsearch
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.
"
What about replacing log4j library directly in elasticsearch/lib directory ?
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
3 Likes
We are using SonarQube 6.7.4, we added the option as noted above “sonar.search.javaAdditionalOpts= -Dlog4j2.formatMsgNoLookups=true”. Is this all we should do? How do we verify it?
Hi @zservati,
Welcome to the community!
Your version is past EOL. You should upgrade to either the latest version or the current LTS immediately. Your upgrade path is:
6.7.4 → 7.9.6 → 8.9.4 → 9.2.2 (last step optional)
You may find the Upgrade Guide and the LTS-to-LTS Upgrade Notes helpful. If you have questions about upgrading, feel free to open a new thread for that here.
Ann
So the suggested remediation is not applicable for 6.7.4, is that right?
Is there anything else we could do without upgrade?
Thanks
A post was split to a new topic: Can SonarQube detect code that used the Log4J2 in a way that is vulnerable?
I just unpacked the SonarQube community release which is part of the Docker distribution (sonarqube:8.9.3-community). It contains a fat jar (sonar-application-8.9.3.48735.jar) which itself seems to contain an older version (2.8.2) of log4j. For this version, however, the quick fix by setting the environment variable (sonar.search.javaAdditionalOpts=-Dlog4j2.formatMsgNoLookups=true) is NOT supposed to work, cf. Log4j – Apache Log4j Security Vulnerabilities
@ganncamp I’m looking at the 8.9.4-developer and 9.2.2-developer docker images and they both have log4j 2.11.1 and I can’t see the noMsg property anywhere. Can you confirm that those releases actually include the update please?
library/sonarqube:9.2.2-developer sh
/opt/sonarqube # find -name ‘*jar’ | grep log
./elasticsearch/lib/log4j-core-2.11.1.jar
./elasticsearch/lib/log4j-api-2.11.1.jar
2 Likes
Hello,
We use SONAR QUBE 7.6
1 – is that vulnerable to the CVE-2021-44228 ???
2 – if YES, then what can we do?
Thanks,
John Dove
John.Dove@its.ny.gov
For older version of SonarQube 6/7 Some suggested on other boards to remove JndiLookup.class from the jar file. I am going to give it a try.
2 Likes
Thanks Zore
Do you know if the above property fix (posting above / top) will work for 7.6?
sonar.search.javaAdditionalOpts=-Dlog4j2.formatMsgNoLookups=true
???
We are seeing the same issue in our vulnerability scanning tools that the vulnerable version of log4j is still present within Sonarqube 9.2.2.
Edit: my mistake, log4j2.formatMsgNoLookups seems to not be set by default on installation.
But as you say, 9.2.2 still use the vulnerable version with additional exploit paths. The best solution would have been to upgrade to the latest safe log4j-core-2.16.0.
Hi @Michael_McCallum, the JVM setting log4j2.formatMsgNoLookups=true is automatically added by SonarQube 8.9.4 and 9.2.2 when starting Elasticsearch. You can verify it by looking at the logs (grep 'JVM arguments' logs/es.log) or in /opt/sonarqube/temp/conf/es/jvm.options. I just ran it on a sonarqube:9.2.2-developer container and can confirm it is set. SonarQube itself does not use log4j2, this setting is only set for the embedded Elasticsearch instance.
1 Like
@Thomas_Chauchefoin This doesn’t seem to affect CVE-2021-45046, which in Apache’s patch notes for 2.16.0 notes “previous mitigations involving configuration such as to set the system property log4j2.noFormatMsgLookup to true do NOT mitigate this specific vulnerability.” SonarQube still uses an elasticsearch version with a vulnerable version of log4j and the applied mitigations are not successful at completely removing the issue. Apache recommends to either upgrade to 2.16.0 or remove the JndiLookup class.
https://logging.apache.org/log4j/2.x/security.html#CVE-2021-45046
1 Like
Hi Thomas, re: the second part why the patched releases still come with vulnerable versions of l4j, I have the same question. Can we expect further releases with L4J 2.16.0 (given the new CVE)?
1 Like
The release notes state explicitly that log4j was upgraded (even if indirectly) which didn’t happen. Hence the question.
@Mol_Olsson the sonar.properties in 9.2.2 (at least docker -developer) does not have a reference to formatMsg…
library/sonarqube:9.2.2-developer sh
/opt/sonarqube # find -name sonar.properties
./conf/sonar.properties
/opt/sonarqube # grep log4j ./conf/sonar.properties
/opt/sonarqube #
/opt/sonarqube # grep -r formatMsgNoLookups .
/opt/sonarqube #
1 Like
Hmm ok, I checked it in our running 9.2.2 enterprise release and it was enabled there.
Edit: I forgot that I set the config myself not relying on default sonarqube config…