CVE-2023-3635 in dependency okio

[hayos]

CVE-2023-3635
Severity: High

+- com.splunk.logging:splunk-library-javalogging:jar:1.11.7:compile
| +- com.squareup.okhttp3:okhttp:jar:4.9.3:compile
| | - com.squareup.okio:okio:jar:2.8.0:compile

References
https://nvd.nist.gov/vuln/detail/CVE-2023-3635
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-3635

Please update okhttp3, so that okio is at least at version 3.4.0.

[dfederschmidt]

Should be addressed by the latest release
https://github.com/splunk/splunk-library-javalogging/releases/tag/1.11.8

[RHackrid]

Release https://github.com/splunk/splunk-library-javalogging/releases/tag/1.11.8 is still vulnerable.

+- com.splunk.logging:splunk-library-javalogging:jar:1.11.8:compile
| +- com.squareup.okhttp3:okhttp:jar:4.10.0:compile
| | +- com.squareup.okio:okio-jvm:jar:3.0.0:compile
| | | +- org.jetbrains.kotlin:kotlin-stdlib-jdk8:jar:1.8.22:compile
| | | | - org.jetbrains.kotlin:kotlin-stdlib-jdk7:jar:1.8.22:compile
| | | - org.jetbrains.kotlin:kotlin-stdlib-common:jar:1.8.22:compile
| - org.jetbrains.kotlin:kotlin-stdlib:jar:1.8.22:compile
| - org.jetbrains:annotations:jar:13.0:compile
| +- com.squareup.okio:okio:jar:3.5.0:compile
| - com.google.code.gson:gson:jar:2.10.1:compile

Force com.squareup.okio:okio to 3.5.0 https://github.com/splunk/splunk-library-javalogging/blob/1.11.8/pom.xml#L232C8-L232C8 will lead to a conflict for the vulnerable package com.squareup.okio:okio-jvm. Excluding com.squareup.okio:okio in com.squareup.okhttp3:okhttp does not work because okhttp depends on okio-jvm (not okio).

com.splunk.logging:splunk-library-javalogging->com.squareup.okhttp3:okhttp depends on com.squareup.okio:okio-jvm only, so I would prefer overwriting the version of this subdependency instead of com.squareup.okio:okio.

[dfederschmidt]

@RHackrid I see - let's try to get to the bottom of this. When I scan the repo dependency-check it comes back clean.

Because splunk-library-javalogging's pom.xml contains 4.11.0.

What I want to understand is why com.squareup.okhttp3:okhttp is resolved to 4.10.0 here in your case? Any ideas?

It seems like okio-jvm is something that only okhttp3:okhttp 4.10.0 and below, not 4.11.0 (For some reason, that artifact name changed for that particular version; See square/okhttp#7351). So I'm not sure how we would go about overwriting this subdependency because 4.11.0 actually depends on okio (see https://mvnrepository.com/artifact/com.squareup.okhttp3/okhttp/4.11.0).

Of course the preferred way to resolve this is to update to a patched version of okhttp3 but that is not available yet.

Thanks again for reaching out and bringing this to our attention.

[RHackrid]

Ok, you are right!

In our projects, we (and maybe a lot of other users) use Spring Boot. Spring Boot overwrites the version of okhttp, so our system will pick 4.10.0 instead of 4.11.0: https://github.com/spring-projects/spring-boot/blob/v3.1.3/spring-boot-project/spring-boot-dependencies/build.gradle#L1065

That is a really unfortunate situation for all Spring Boot projects, but I think com.splunk.logging:splunk-library-javalogging is doing fine.

Spring Boot projects will still have to override okio-jvm by themselves until spring boot releases an updated okhttp.version (spring-projects/spring-boot@2ce6458):

    <dependency>
      <groupId>com.squareup.okio</groupId>
      <artifactId>okio-jvm</artifactId>
      <version>3.5.0</version>
    </dependency>

I apologize for the circumstances.

[jvwilge]

For spring boot projects I think it is cleaner to override the version the 'spring way'.

In Maven add this to your pom.xml:

<properties><okhttp.version>4.11.0</okhttp.version></properties>

(remove this property once spring boot uses this, or a higher version).