Vulnerability in dependency of jnr-unixsocket

[moegyver]

Hi!

Our internal vulnerability scanning shows that jnr-unixsocket 0.36 has jnr-posix 3.0.61 as dependency which is vulnerable.

See https://security.snyk.io/vuln/SNYK-JAVA-COMGITHUBJNR-1570422, jnr-unixsocket has updated the dependency in later versions.

Updating to a never version of jnr-posix should solve this.

Please shout if you have questions.

[jverga23]

Hi, thank you for reporting this. I work on the Vulnerability Management team here at Datadog and we are doing some internal investigation. I will reach out when I have more information to share

[jverga23]

@moegyver please see below for an update regarding this CVE

While it would be nice to patch this issue and remove the CVE, it is largely out-of-scope within the use the jnr-unixsocket library makes of jnr-posix. We should be largely unaffected by the problem. Additionally, there's another major constraint which prevents us from just blindly bumping jnr-unixsocket to a more current version; the java-dogstatsd-client currently supports Java 1.7 and any update to the library would make us drop Java 1.7 support and increase our minimum JRE env to Java8, we would like to avoid this. For your and our peace of mind: both RHEL and Ubuntu have labeled the CVE impact as low despite NVD interpretation of the bug, see:

https://ubuntu.com/security/CVE-2014-4043
https://access.redhat.com/security/cve/CVE-2014-4043
#155 (comment)

Please let us know if you have further questions or concerns.

[ph4r05]

I am wondering, is there any progress on this decision? We are using DD in our company services and due to company security policies we have to address this somehow as it keeps popping up on our security scans.

So we were wondering, would it be possible to release another artifact that is for java8+? Popular crypto JCA/JCE library BouncyCastle adopted similar approach, releasing several JARs with minimal JDK version required (https://www.bouncycastle.org/latest_releases.html).

It would help us greatly and I believe it would be also better for DD to get rid of this security finding.

Thanks!