[FP]: "reserved" CVE-2023-4586 gets flagged on a Netty dependency

[volkert-fastned]

Package URl

pkg:maven/io.netty/[email protected]

CPE

cpe:2.3:a:netty:netty:4.1.97:*:*:*:*:*:*:*

CVE

CVE-2023-4586

ODC Integration

Gradle Plugin

ODC Version

8.4.0

Description

This is a weird one. Vulnerability CVE-2023-4586 gets flagged on a Netty dependency, but this CVE doesn't appear to exist (yet?):

• https://nvd.nist.gov/vuln/detail/CVE-2023-4586 -> "CVE ID Not Found"
• https://www.cve.org/CVERecord?id=CVE-2023-4586 -> "This ID has been reserved by a CNA."

[github-actions[bot]]

Maven Coordinates

<dependency>
   <groupId>io.netty</groupId>
   <artifactId>netty-handler</artifactId>
   <version>4.1.97.Final</version>
</dependency>

Suppression rule:

<suppress base="true">
   <notes><![CDATA[
   FP per issue #5912
   ]]></notes>
   <packageUrl regex="true">^pkg:maven/io\.netty/netty-handler@.*$</packageUrl>
   <cpe>cpe:/a:netty:netty</cpe>
</suppress>

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

[github-actions[bot]]

Maven Coordinates

<dependency>
   <groupId>io.netty</groupId>
   <artifactId>netty-handler</artifactId>
   <version>4.1.97.Final</version>
</dependency>

Suppression rule:

<suppress base="true">
   <notes><![CDATA[
   FP per issue #5912
   ]]></notes>
   <packageUrl regex="true">^pkg:maven/io\.netty/netty-handler@.*$</packageUrl>
   <cpe>cpe:/a:netty:netty</cpe>
</suppress>

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

[github-actions[bot]]

Maven Coordinates

<dependency>
   <groupId>io.netty</groupId>
   <artifactId>netty-handler</artifactId>
   <version>4.1.97.Final</version>
</dependency>

Suppression rule:

<suppress base="true">
   <notes><![CDATA[
   FP per issue #5912
   ]]></notes>
   <packageUrl regex="true">^pkg:maven/io\.netty/netty-handler@.*$</packageUrl>
   <cpe>cpe:/a:netty:netty</cpe>
</suppress>

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

[volkert-fastned]

A Google search shows up very few results. Red Hat has a page on vulnerability CVE-2023-4586, and it seems to pertain to something called the "Hot Rod client". Not sure why the CPE targets Netty. It might be that the vulnerability was discovered in the Hot Rod client, and the underlying cause was localized in Netty.

[volkert-fastned]

Indeed, the Infinispan Hot Rod client appears to have Netty as a dependency: https://mvnrepository.com/artifact/org.infinispan/infinispan-client-hotrod/15.0.0.Dev02

[volkert-fastned]

So this might not be a FP after all. But no stable Netty version beyond the exact version specified in the CPE (4.1.97) has been released yet. The CPE also implies that no other version (including earlier versions of Netty) would be affected, which I find to be unlikely.

[github-actions[bot]]

Maven Coordinates

<dependency>
   <groupId>io.netty</groupId>
   <artifactId>netty-handler</artifactId>
   <version>4.1.97.Final</version>
</dependency>

Suppression rule:

<suppress base="true">
   <notes><![CDATA[
   FP per issue #5912
   ]]></notes>
   <packageUrl regex="true">^pkg:maven/io\.netty/netty-handler@.*$</packageUrl>
   <cpe>cpe:/a:netty:netty</cpe>
</suppress>

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

[volkert-fastned]

Okay, I followed the links that OSSINDEX referred to, and ended up in the following GitHub threads:

• https://github.com/netty/netty/issues/8537
• https://github.com/netty/netty/issues/9930

Specifically the following comments:

• https://github.com/netty/netty/issues/8537#issuecomment-1527896917
• https://github.com/netty/netty/issues/9930#issuecomment-572578899

So it appears that this is a disputed vulnerability.

[volkert-fastned]

Mitre now has a page for this vulnerability, status still at "reserved": https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-4586

Nothing on NIST yet, but NIST does not publish CVEs while they still have a "reserved" status.

NOTE: CVE-2023-4586 is not to be confused with CVE-2023-40586 (with a zero between the 4 and the 5), which is an unrelated vulnerability. I'm mentioning this, since the latter vulnerability sometimes comes up in search results when looking for the former.

[aikebah]

@volkert-fastned This finding comes from OSSIndex. Their API yields the vulnerabilities for a given library, hence there is no range indication. NVD on the other hand reports vulnerabilities and as an attribute of it the CPEs it considers the subject of the CVE.

That's why for NVD results there is the range to be found in ODCs results, but for OSSIndex entries there is only the one version for which the known vulnerabilities were requested in their API.

[aikebah]

Whether or not it's a false positive in your case depends on whether you explicitly enabled the hostname verification in your codebase (if not it's a true positive - due to the insecure default)

[sjamaan]

NOTE: This same CVE suddenly popped up again, this time for netty-transport

[aikebah]

@sjamaan as indicated already in earlier comments: the CVE is about an insecure default in Netty as flagged by OSSIndex (follow the link in earlier comment https://github.com/jeremylong/DependencyCheck/issues/5912#issuecomment-1699387994 to the Netty issue). Only when you take the effort to code a few more lines to enable TLS hostname verification Netty can truly be trusted upon for TLS connections. In the Netty project they've indicated that they consider it sufficient to change the default in a future major release (as changing the default may break existing setups that currently rely on the non-validating default)

[sjamaan]

@sjamaan as indicated already in earlier comments: the CVE is about an insecure default in Netty as flagged by OSSIndex (follow the link in earlier comment #5912 (comment) to the Netty issue). Only when you take the effort to code a few more lines to enable TLS hostname verification Netty can truly be trusted upon for TLS connections. In the Netty project they've indicated that they consider it sufficient to change the default in a future major release (as changing the default may break existing setups that currently rely on the non-validating default)

Thanks @aikebah but that much was clear and we're already doing that in our project. We've suppressed the CVE on netty-handler back in August. But today our CI suddenly started complaining about netty-transport. And after suppressing that, it started complaining about netty-transport-classes-epoll. I'm not sure where these new warnings are coming from, but we've simply suppressed it like this now:

  <suppress>
   <notes><![CDATA[
   Fixed via by manually setting up TLS hostname verification
   until upstream fix is available
   ]]></notes>
   <packageUrl regex="true">^pkg:maven/io\.netty/netty-.*@.*$</packageUrl>
   <cve>CVE-2023-4586</cve>
  </suppress>

[aikebah]

@sjamaan Right... that's because this CVE has now reached a 'published' state with Red Hat's Hot Rod client as the messenger to move it forward to a published state, so now it also landed in NIST NVD, causing the usual textual similarity matches (jar-file to CPE mapping logic) with unrelated netty libraries to also appear (before that it was only found by ODC in OSSIndex linked directly at the netty libraries affected by it)

[sjamaan]

Thanks for elaborating on that, much appreciated!

[jpcmonster]

An odd (?) twist here (maybe). https://nvd.nist.gov/vuln/detail/CVE-2023-4586 indicates "Up to (including) 4.1.99". 4.1.100 seems to have released more-or-less coincidentally with the NIST publication of CVE-2023-4586. Prior to 4.1.100 it seemed a range of discrete Netty jars were flagged. With 4.1.100 there is now a single line warning from DependencyCheck:

netty-handler-4.1.100.Final.jar (pkg:maven/io.netty/[email protected], cpe:2.3:a:netty:netty:4.1.100:*:*:*:*:*:*:*) : CVE-2023-4586

Not sure this is helpful or relevant, but wanted to note it for others.

[tjdett]

As noted in netty/netty#13665, the Netty advisory for CVE-2023-4586 has now been withdrawn: https://github.com/advisories/GHSA-57m8-f3v5-hm5m

[lackovic]

As noted in netty/netty#13665, the Netty advisory for CVE-2023-4586 has now been withdrawn: GHSA-57m8-f3v5-hm5m

From this I understand the vulnerability warning from netty-handler can now be safely considered as false positive.

Is that valid also for the other netty dependencies flagged with the same vulnerability?

• netty-buffer
• netty-codec
• netty-common
• netty-handler-proxy
• netty-resolver
• netty-transport

netty-buffer-4.1.101.Final.jar (pkg:maven/io.netty/[email protected], cpe:2.3:a:netty:netty:4.1.101:*:*:*:*:*:*:*) : CVE-2023-4586
netty-codec-4.1.101.Final.jar (pkg:maven/io.netty/[email protected], cpe:2.3:a:netty:netty:4.1.101:*:*:*:*:*:*:*) : CVE-2023-4586
netty-codec-dns-4.1.101.Final.jar (pkg:maven/io.netty/[email protected], cpe:2.3:a:netty:netty:4.1.101:*:*:*:*:*:*:*) : CVE-2023-4586
netty-codec-http-4.1.101.Final.jar (pkg:maven/io.netty/[email protected], cpe:2.3:a:netty:netty:4.1.101:*:*:*:*:*:*:*) : CVE-2023-4586
netty-codec-http2-4.1.101.Final.jar (pkg:maven/io.netty/[email protected], cpe:2.3:a:netty:netty:4.1.101:*:*:*:*:*:*:*) : CVE-2023-4586
netty-codec-socks-4.1.101.Final.jar (pkg:maven/io.netty/[email protected], cpe:2.3:a:netty:netty:4.1.101:*:*:*:*:*:*:*) : CVE-2023-4586
netty-common-4.1.101.Final.jar (pkg:maven/io.netty/[email protected], cpe:2.3:a:netty:netty:4.1.101:*:*:*:*:*:*:*) : CVE-2023-4586
netty-handler-4.1.101.Final.jar (pkg:maven/io.netty/[email protected], cpe:2.3:a:netty:netty:4.1.101:*:*:*:*:*:*:*) : CVE-2023-4586
netty-handler-proxy-4.1.101.Final.jar (pkg:maven/io.netty/[email protected], cpe:2.3:a:netty:netty:4.1.101:*:*:*:*:*:*:*) : CVE-2023-4586
netty-resolver-4.1.101.Final.jar (pkg:maven/io.netty/[email protected], cpe:2.3:a:netty:netty:4.1.101:*:*:*:*:*:*:*) : CVE-2023-4586
netty-resolver-dns-4.1.101.Final.jar (pkg:maven/io.netty/[email protected], cpe:2.3:a:netty:netty:4.1.101:*:*:*:*:*:*:*) : CVE-2023-4586
netty-resolver-dns-classes-macos-4.1.101.Final.jar (pkg:maven/io.netty/[email protected], cpe:2.3:a:netty:netty:4.1.101:*:*:*:*:*:*:*) : CVE-2023-4586
netty-resolver-dns-native-macos-4.1.101.Final-osx-x86_64.jar (pkg:maven/io.netty/[email protected], cpe:2.3:a:netty:netty:4.1.101:*:*:*:*:*:*:*) : CVE-2023-4586
netty-transport-4.1.101.Final.jar (pkg:maven/io.netty/[email protected], cpe:2.3:a:netty:netty:4.1.101:*:*:*:*:*:*:*) : CVE-2023-4586
netty-transport-classes-epoll-4.1.101.Final.jar (pkg:maven/io.netty/[email protected], cpe:2.3:a:netty:netty:4.1.101:*:*:*:*:*:*:*) : CVE-2023-4586
netty-transport-native-epoll-4.1.101.Final-linux-x86_64.jar (pkg:maven/io.netty/[email protected], cpe:2.3:a:netty:netty:4.1.101:*:*:*:*:*:*:*) : CVE-2023-4586
netty-transport-native-unix-common-4.1.101.Final.jar (pkg:maven/io.netty/[email protected], cpe:2.3:a:netty:netty:4.1.101:*:*:*:*:*:*:*) : CVE-2023-4586

[Dhanxy]

This is false positive or no?

[DGoyal29]

Can anyone update whether it is a false positive or not?

[chadlwilson]

You shouldn't be seeing this reported against Netty in an ODC report now, as the upstream data has been fixed in NVD, OSSIndex and GHSA, and this CVE is no longer linked to Netty (reported against Infinispan Hotrod Client usage of netty instead)

I don't see OSSIndex linking it to any Netty components, and think this issue should be closed now.

If you still see it, please share the specific package coordinates it is being reported against?