CVE-2022-45688 in org.json/json - misleading CPE

[TamasPergerDWP]

Package URl

pkg:maven/org.json/json@20220924

CPE

cpe:2.3:a:hutool:hutool:5.8.10:*:*:*:*:*:*:*

CVE

CVE-2022-45688

ODC Integration

{"label"=>"Maven Plugin"}

ODC Version

8.0.2

Description

The cpe on the NIST site: cpe:2.3:a:hutool:hutool:5.8.10:*:*:*:*:*:*:* does not seem related to org.json/json

[github-actions]

Maven Coordinates

<dependency>
   <groupId>org.json</groupId>
   <artifactId>json</artifactId>
   <version>20220924</version>
</dependency>

Suppression rule:

<suppress base="true">
   <notes><![CDATA[
   FP per issue #5401
   ]]></notes>
   <packageUrl regex="true">^pkg:maven/org\.json/json@.*$</packageUrl>
   <cpe>cpe:/a:hutool:hutool</cpe>
</suppress>

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

[github-actions]

Maven Coordinates

<dependency>
   <groupId>org.json</groupId>
   <artifactId>json</artifactId>
   <version>20220924</version>
</dependency>

Suppression rule:

<suppress base="true">
   <notes><![CDATA[
   FP per issue #5401
   ]]></notes>
   <packageUrl regex="true">^pkg:maven/org\.json/json@.*$</packageUrl>
   <cpe>cpe:/a:hutool:hutool</cpe>
</suppress>

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

[melloware]

Its also finding it for HazelCast.

hazelcast-5.1.3.jar/META-INF/maven/org.json/json/pom.xml (pkg:maven/org.json/json@20220320) : CVE-2022-45688
json-20220924.jar (pkg:maven/org.json/json@20220924) : CVE-2022-45688

[mprins]

I think this CVE does apply to org.json:json see stleary/JSON-java#708

[melloware]

I think this CVE does apply to org.json:json see stleary/JSON-java#708

Its strange the CVE doesn't mention anything about org.json though?

[TamasPergerDWP]

It seems the CPE is misleading on the NIST site; another CPE should be added that refers to the org.json/json package.

According to stleary/JSON-java#708, this seems to be a REAL positive.

[github-actions]

Maven Coordinates

<dependency>
   <groupId>org.json</groupId>
   <artifactId>json</artifactId>
   <version>20220924</version>
</dependency>

Suppression rule:

<suppress base="true">
   <notes><![CDATA[
   FP per issue #5401
   ]]></notes>
   <packageUrl regex="true">^pkg:maven/org\.json/json@.*$</packageUrl>
   <cpe>cpe:/a:hutool:hutool</cpe>
</suppress>

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

[melloware]

Agreed it needs its own CVE but Hazlecast still looks like a false positive.

[TamasPergerDWP]

Agreed it needs its own CVE but Hazlecast still looks like a false positive.

It seems to me that Hazelcast bundles the org.json/json package (having relocated it as com.hazelcast.org.json package), so I think it is a real issue there.

[melloware]

OK you are right I think a lot of projects shade the JSON jar so this will be pretty pervasive. Yikes!

[blutorange]

a lot of projects shade the JSON jar so this will be pretty pervasive

Yeah, PrimeFaces shades it as well. At first I had been wondering too why it shows PrimeFaces, but then I remembered that it does shade it.

[ERROR] primefaces-11.0.8.jar/META-INF/maven/org.json/json/pom.xml: CVE-2022-45688(7.5)

[melloware]

Yep

[sjamaan]

Agreed it needs its own CVE but Hazlecast still looks like a false positive.

It seems to me that Hazelcast bundles the org.json/json package (having relocated it as com.hazelcast.org.json package), so I think it is a real issue there.

How did you determine it is doing that?

I'm asking because I also see various Google packages mentioned in my project:

• pkg:maven/com.google.api/gax-httpjson@0.104.4
• pkg:maven/com.google.api-client/google-api-client-gson@2.0.0
• pkg:maven/com.google.http-client/google-http-client-gson@1.42.2

Funny thing is, if you follow those links to the Sonatype site, it tells you there's no known vulnerability! I'm deeply confused by the report output, to be honest.

For instance, the evidence for google-http-client-gson is:

Type	Source	Name	Value	Confidence
Vendor	file	name	google-http-client-gson	High
Vendor	jar	package name	api	Highest
Vendor	jar	package name	client	Highest
Vendor	jar	package name	google	Highest
Vendor	jar	package name	json	Highest
Vendor	Manifest	automatic-module-name	com.google.api.client.json.gson	Medium
Vendor	Manifest	build-jdk-spec	1.8	Low
Vendor	pom	artifactid	google-http-client-gson	Low
Vendor	pom	groupid	com.google.http-client	Highest
Vendor	pom	name	GSON extensions to the Google HTTP Client Library for Java.	High
Vendor	pom	parent-artifactid	google-http-client-parent	Low
Product	file	name	google-http-client-gson	High
Product	jar	package name	api	Highest
Product	jar	package name	client	Highest
Product	jar	package name	google	Highest
Product	jar	package name	json	Highest
Product	Manifest	automatic-module-name	com.google.api.client.json.gson	Medium
Product	Manifest	build-jdk-spec	1.8	Low
Product	pom	artifactid	google-http-client-gson	Highest
Product	pom	groupid	com.google.http-client	Highest
Product	pom	name	GSON extensions to the Google HTTP Client Library for Java.	High
Product	pom	parent-artifactid	google-http-client-parent	Medium
Version	file	version	1.42.2	High
Version	pom	version	1.42.2	Highest

So the highest ones like vendor having "google" in the name or com.google.http-client in the groupid (for pkg:maven/com.google.http-client/google-http-client-gson@1.42.2  (Confidence:High)) IMHO do not match the corresponding CVE's cpe, which is cpe:2.3:a:json-java_project:json-java:::::::: versions up to (excluding) 20220924

How can I be sure it's a false positive (or not), if I am unable to figure out what causes the match to be made?

[TamasPergerDWP]

How can I be sure it's a false positive (or not), if I am unable to figure out what causes the match to be made?

@sjamaan : First of all, make sure you use the latest (8.1.1) version of the dependency check - many false positives were eliminated there

[sjamaan]

How can I be sure it's a false positive (or not), if I am unable to figure out what causes the match to be made?

@sjamaan : First of all, make sure you use the latest (8.1.1) version of the dependency check - many false positives were eliminated there

Many thanks, that did the trick indeed! Was this due to a bug, or am I somehow still misunderstanding the matching process?

[TamasPergerDWP]

@sjamaan : From my experience, the pattern matching heuristics is a bit prone to err on the safe side, marking packages suspected to be affected even when they are actually not. The more serious over-eagerness (a.k.a. false positive) cases are handled by adding exceptions/suppressions inside the checker tool (like the change between versions 8.1.0 -> 8.1.1)

[sjamaan]

@sjamaan : From my experience, the pattern matching heuristics is a bit prone to err on the safe side, marking packages suspected to be affected even when they are actually not. The more serious over-eagerness (a.k.a. false positive) cases are handled by adding exceptions/suppressions inside the checker tool (like the change between versions 8.1.0 -> 8.1.1)

I get that, but how can you tell specifically why the package matched against a CVE? I thought the "evidence" was for that, but if that's the case I couldn't figure out how the confidence is derived.

[TamasPergerDWP]

@sjamaan : From my experience, the pattern matching heuristics is a bit prone to err on the safe side, marking packages suspected to be affected even when they are actually not. The more serious over-eagerness (a.k.a. false positive) cases are handled by adding exceptions/suppressions inside the checker tool (like the change between versions 8.1.0 -> 8.1.1)

I get that, but how can you tell specifically why the package matched against a CVE? I thought the "evidence" was for that, but if that's the case I couldn't figure out how the confidence is derived.

I think this is a question for @jeremylong - I am not familiar with the internals of the tool.