Vulnerabilities reported by Veracode

[iHarishKumar]

Hi,

We got the following issues when we ran Veracode testing our code.

1. Process Control (CWE ID 114) File: Native.java Line No: 105 Reason: The statement contains the hardcoded value for looking up the jar file with a specific pattern.

2. Insufficient Entropy (CWE ID 331) File: XXHashFactory.java Line No: 185, 186 Reason: Not sure if this is providing enough randomness.

3. External Control of File Name or Path (CWE ID 73) File: Native.java Line No: 72, 73, 113 Reason: Here, it is trying to access the file system. The path provided may be malicious.

The Jar that we are using is lz4-java-1.7.1.jar. Please do let us know if these issues are false positives or acceptable. Also, let me know if you need more information.

Thanks, Harish Gunjalli

[odaira]

To me, they all look like false positives, but please elaborate more on what specific scenarios could lead to vulnerabilities at those places, if you would like me to investigate further.

[shyam94]

Hi odaira,

I'll try to provide some more info. about those 3 vulnerabilities:

1. Since the statement contains the hardcoded value, it's quite possible that attacker puts a different library with the same name that is hardcoded and could be malicious if executed. (More details on CWE ID 114).

2. The statement is using java.util.random to provide randomness but it doesn't seems to provide enough randomness. (More details on CWE ID 331)

3. The path provided could be malicious because an attacker may alter the path in any of the 3 cases. (More details on CWE ID 73).

Please go through the CWE details of each part and let me know if these are false positives or needs to be addressed.

Thanks, Shyam Joshi

[jmgomez77]

Hello,

We're investigating this issue since lz4-java is a dependency of Kafka and we use Veracode for the security audit.

As CWE explains, the problem is relying on the environment for loading a library, which could be replaced by an attacker who would place the bogus library upper in the search path.

net/jpountz/util/Native.java:107 loads the native library "lz4-java" from the java.library.path.

    // Try to load lz4-java (liblz4-java.so on Linux) from the java.library.path.
    try {
      System.loadLibrary("lz4-java");
      loaded = true;
      return;
    } catch (UnsatisfiedLinkError ex) {
      // Doesn't exist, so proceed to loading bundled library.
    }

I don't understand why Veracode considers this as Very High since it require an attacker to have access to the target environment in first place in order to place the hacked library in a directory included in java.library.path preceding the place where the original library is to be found. Using a hardcoded path would be regarded as "safer" but the installation directory or current working directory aren't known, so I'm not sure if using a relative path such as "./lz4-java" is an acceptable solution, or whether this is an actual issue.