Does squid:S4721 pick up use of ProcessBuilder?

java
sonarqube

(Alain O'Dea) #1
  • which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)
    SonarQube Enterprise 7.4.0.18908

  • what are you trying to achieve
    I would like to know if squid:S4721 picks up uses of ProcessBuilder.

  • what have you tried so far to achieve this
    Read the docs for squid:S4721.


(Nicolas Peru) #2

Hi,

I am really not sure I understand what you mean by “pick up” here.
From the documentation : https://rules.sonarsource.com/java/RSPEC-4721

ProcessBuilder constructor and command methods will only raise issue if they are used with an argument. No issue will be raised if they are used without an argument.

This can also be seen on the test file of the analyzer : https://github.com/SonarSource/sonar-java/blob/8946e75907b61d94622217fab424c9db909f5702/java-checks/src/test/files/checks/security/ExecCallCheck.java#L39 Issues will be raised on lines with // Noncompliant comment.

Hope this helps.


(Alain O'Dea) #3

Sorry, I was quite vague in my question.

Here is a snippet of the code we were hoping would get marked as an issue:

ProcessBuilder processBuilder = new ProcessBuilder().command(command);
Process process = processBuilder.start();

command is a non-constant string.


(Nicolas Peru) #4

Hi,
If I understand correctly, you do not have an issue raised on this snippet ?
I just tested this code snippet with command as String parameter of a wrapping method and an issue is raised as expected.
I am really still not sure what is the problem here.


(Alain O'Dea) #5

Odd. It wasn’t raised on the pull request I tried. I’ll run another set of examples of this and see if the issue gets raised on them.


(Alain O'Dea) #6

I just ran this code through and it did not flag it:


import java.io.IOException;

public interface SonarQubeSquidS4721ProcessBuilder
{
    static void main(String[] args) throws IOException, InterruptedException
    {
        ProcessBuilder processBuilder = new ProcessBuilder();
        processBuilder.command(args);
        Process process = processBuilder.start();
        int exitValue = process.waitFor();
        System.exit(exitValue);
    }
}

This line is unsafe and should be flagged:

processBuilder.command(args);

SonarQubeSquidS4721ProcessBuilder.java appears in the code scanned for the PR and is navigable in the SonarQube web UI.


(Nicolas Peru) #7

I just ran your sample in our unit test suite and it is properly detected : is the rule activated in your quality profile ? can you share the log of the analysis ?
What is the sonarjava version installed on your sonarqube instance ?
The problem of false negative does not seem to be related to the rule itself but to something else.


(Alain O'Dea) #8

I think it may be an issue with GitHub Enterprise merge branches in the presence of branch conflicts. I’ve been doing some more testing to isolate the issue.


(Alain O'Dea) #9

squid:S4721 and squid:S2076 are activated in the quality profile used.

SonarJava 5.10.1 (build 16922) is installed on our SonarQube instance.

SonarLint also doesn’t pick it up. It picks up vulnerable JDBC usages, but not vulnerable ProcessBuilder or Runtime.getRuntime().exec usages.

I’m going to retry with a full clone (not a shallow clone) and SonarJava 5.10.2.


(Alain O'Dea) #10

The Sonar Scanner log in Jenkins shows several entries like:
File '/home/jenkins/workspace/Example_example_PR-12345/com/example/SonarQubeSquidS4721ProcessBuilder.java' was detected as changed but without having changed lines

That log comes up almost 22,000 times, each time for a different file.

It also logs about missing commits:
org.eclipse.jgit.errors.MissingObjectException: Missing commit

I have been running the analysis on the merge branch, because running it on the PR branch was causing Sonar to report issues from the base branch. This seems to be working well otherwise.

The full log is massive and would be quite painful to sanitize to share here.


(Alain O'Dea) #11

No luck with a full clone of the merge branch either. I have confirmed that the GitHub merge branch has the vulnerable Java examples I am testing.

The log in Jenkins only shows a single warning about encoding and shows 0 issues. Oddly the Gradle plug-in does not appear to log the scanner-cli output, so it’s very quiet relative to running the scanner-cli directly.

Here is the sanitized Scanner Context for that scan:
scanner-context.txt (46.3 KB)