[FP]: False positive for msal4j@1.17.1 against CVE-2024-35255

[jubui]

Package URl

pkg:maven/com.microsoft.azure/msal4j@1.17.1

CPE

cpe:2.3:a:microsoft:authentication_library:1.17.1:*:*:*:*:*:*:*

CVE

CVE-2024-35255

ODC Integration

None

ODC Version

10.0.3

Description

CVE-2024-35255 reports this only affects the java version Up to (excluding 1.15.1) so 1.17.1 should not be affected here. Msal4j is the Microsoft Authentication Library for Java.

[github-actions[bot]]

Maven Coordinates

<dependency>
   <groupId>com.microsoft.azure</groupId>
   <artifactId>msal4j</artifactId>
   <version>1.17.1</version>
</dependency>

Suppression rule:

<suppress base="true">
   <notes><![CDATA[
   FP per issue #7050
   ]]></notes>
   <packageUrl regex="true">^pkg:maven/com\.microsoft\.azure/msal4j@.*$</packageUrl>
   <cpe>cpe:/a:microsoft:authentication_library</cpe>
</suppress>

Link to test results: https://github.com/jeremylong/DependencyCheck/actions/runs/11347636949

[aikebah]

similar to #7000, see https://github.com/jeremylong/DependencyCheck/issues/7000#issuecomment-2417434590

[jubui]

@aikebah I am not following. Does this mean it's fixable on your end?

From https://github.com/jeremylong/DependencyCheck/issues/7049#issuecomment-2417452277 it sounds like msal4j is similar in that it's a small subcomponent (one language variant) of the overall CPE product so sounds like we just have to suppress this?

[aikebah]

@jubui For msal4j there is a discriminator for the language in which the authentication library is coded. The reason for this FP is that there are in NVD different CPEs for the java implementation (cpe:2.3:a:microsoft:authentication_library:*:*:*:*:*:java:*:*) which is vulnerable up to (excluding) version 1.15.1, nodejs (cpe:2.3:a:microsoft:authentication_library:*:*:*:*:*:node.js:*:*) vulnerable up to (excluding) version 2.9.2 and dotnet (cpe:2.3:a:microsoft:authentication_library:*:*:*:*:*:.net:*:*) vulnerable up to (excluding) 4.61.3

As NVD is using a different CPE-identifier for them it would in principle be possible to differentiate between them in ODC as well, if we find a good way to enhance the analyzers to take the discriminating field of the CPE (target_sw) into account in the matching logic. Hence resolving this one is blocked by an enhancement that would allow us to map the right CPE (support discrimination on the target_sw field of the CPE)

For lucene however the NVD has only a single CPE-identifier that is used for a CVE in any of the libraries of the project, so we cannot in any way make ODC map to the subvariant of the CPE for a single sublibrary of lucene (those simply do not exist in NVD) - we would only be able to differentiate if we would build our own dataset of which CVE is mapped to which sublibrary of the CPE. Building such a DB is out-of-scope for us, so people should upgrade to latest Lucene version if they don't want to take the effort to triage which library/ies of lucene are affected by a vulnerability reported on Lucene.

[jubui]

Ah ok, so while it is technically feasible for you to do it on your end, it will require an enhancement. So on my end, I should just suppress this instead of waiting for it to be addressed on your end. Thanks, that answers my question.

[aikebah]

The following suppression would cover it for quite some time as a workaround, assuming no 3-digit minor versions appear for the library and a long time will pass before major 10 sees the light for this library (while avoiding the risk of suppressing this CVE on older versions of msal4j or suppressing newly emerging CVEs):

<suppress>
   <notes><![CDATA[
   Workaround for false positive per issue https://github.com/jeremylong/DependencyCheck/issues/7050
   ]]></notes>
   <packageUrl regex="true">^pkg:maven/com\.microsoft\.azure/msal4j@(1\.15\.[1-9]|[2-9]|1\.1[6-9]).*$</packageUrl>
   <cve>CVE-2024-35255</cve>
</suppress>