SonarQube, SonarCloud, and the Log4J vulnerability

Clean Code Sonar Updates
21

I’ve done some research because we’re running version 7.4, and concluded that the formatMsgNoLookups fix won’t do.
In our scenario, Sonarqube 7.4 depends on Elasticsearch component version 5.6.3, which in turn bundles version 2.9.1 of log4j library.
The formatMsgNoLookups parameter is only supported on log4j versions 2.10 and above, so passing this parameter won’t do anything.
There’s an official statement from Elasticsearch that seems to indicate that versions 5.5+ should support the fix, but in our case at least the installed log4j version says otherwise.

22

What about the sonar scanner components (standalone and sonar-maven-plugin)? Could those be vulnerable to this? @ganncamp

1 Like
23

We still have 7.9 LTS DCE instance, waiting for business to approve migration to 8.9 LTS DCE. Is there any solution you are would be suggesting for 7.9 LTS DCE ? Thanks

24

Per log4j:

For releases >=2.0-beta9 and <=2.10.0, the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

26

You can/must pass multiple values to the property by space separating the value on one line (don’t use commas or semi-colons)
Setting the property twice will result in the last ‘set’ taking affect only

27

Hi,

You said today you published a new release of SonarQube to update Log4j.
Could you please tell me when this new version will be available on DockerHub (i’m using 8.9.2 Developer edition LTS) ?

Thanks

28

Is there a way that we can look in SonarQube to verify if the component mentioned below is being used?

SonarQube includes a component from ElasticSearch that contains a Log4J component.

29

Hello Ann,

Could you please indicate whether version 8.3 SQ Enterprise Data center edition would be affected by the Log4J vulnerability, and if so, what steps could we take to remediate the issue? Would it be the same as you have indicated above, by adding the javaAdditionalOpts property?

Best,
Simon

30

On that topic, we are running 8.3 SQ in HA mode and currently do not have any bandwidth to take on upgrade work.

If we CANNOT upgrade, what do you recommend developers and team do to resolve the Log4J vulnerability?

-Simon

31

Hi all,

Fair question. Our internal analysis indicates we don’t use Log4J in the Scanners, so there’s no vulnerability.

Regarding all the other questions about non-latest, non-LTS versions, again, only latest (9.2.1) and LTS (8.9.3) are supported. We have not investigated other versions, since we don’t support them. If you have concerns, you should upgrade.

 
Ann

1 Like
32

Hi - Thank you for providing details to mitigate the risk.
We are using “Community EditionVersion 7.9.4”.
Does adding this “sonar.search.javaAdditionalOpts=-Dlog4j2.formatMsgNoLookups=true” to sonar.properties and restart instance helps us to mitigate the risk ?

Please suggest on this.

Thank you,
Ravi

33

Another question…We also have ElasticSearch and their vendor has recommended applying flag “-Dlog4j2.formatMsgNoLookups=true” to ElasticSearch. If that flag is applied in ElasticSearch does it also take care of the component that SonarQube uses from ElasticSearch?

34

Hi @hurstji,

Adding the flag for SonarQube will take care of SonarQube’s embedded Elasticsearch.

 
Ann

35

Hello @ganncamp - Since you deployed a new version with updated Log4J for SonarCloud, are there plans to publish a new release for SonarQube 8.9.x LTS?

Also, if you can share - What would be the impact of replacing the log4j-api and log4j-core jar files in sonarqube-8.9.3.48735/elasticsearch/lib directory with the latest log4j jar files? Will it work or are there chances that it will break something in SonarQube?

We have made the recommended change to sonar.properties and also added the system level environment variable for the same as an additional check, but it would be great to upgrade to an updated version of Log4J.

4 Likes
36

Hi @ganncamp, just want to echo @saurabhdeep, can you share if and when SonarQube will be updated so that the bundled elasticsearch will have the latest log4j2 library?

1 Like
37

Hi, We are currently using SonarQube 7.1 and have no immediate plans to upgrade to the latest LTS any time soon.

Would it be sufficient if we apply the mitigation steps to remove the JndiLookup.Class file from elasticsearch/lib folder?

38

Is sonarqube 7.9.5 impacted by this vulnerability? If yes does adding that line to sonar.properties file remidiates the vulnerability in sonarqube 7.9.5?

39

It seems the default setting is #sonar.search.javaAdditionalOpts= . (commented out) Does this imply it is already safe?

40

@ganncamp How do we handle this in official helm chart? Do we need to add sonar.search.javaAdditionalOpts: “-Dlog4j2.formatMsgNoLookups=true” under sonarProperties node in values.yaml file?

41

@Rahul_Mahulkar yes, or you can set a new env to configure this in the official helm chart

env:
    - name: SONAR_SEARCH_JAVAADDITIONALOPTS
      value: "-Dlog4j2.formatMsgNoLookups=true"
2 Likes