Security Fix: Okio CVE-2023-3635 + OkHttp Jar Update

[Mariamalmesfer]

Description

This PR fixes the Okio security vulnerability (CVE-2023-3635) by upgrading from version 1.17.2 to 3.6.0. It also includes an update to the OkHttp jar from 3.9.0 to 4.12.0

Motivation and Context

A flaw was found in Okio’s GzipSource class that doesn’t handle exceptions properly, allowing potential Denial of Service (DoS) attacks with malformed files.

CVE-2023-3635: Details

Impact

Image Scan showed the vulnerability have been removed.
correlation-report-ibm-lh-presto-okie check.csv

Test Plan

Contributor checklist

• Please make sure your submission complies with our development, formatting, commit message, and attribution guidelines.
• PR description addresses the issue accurately and concisely. If the change is non-trivial, a GitHub Issue is referenced.
• Documented new properties (with its default value), SQL syntax, functions, or other functionality.
• If release notes are required, they follow the release notes guidelines.
• Adequate tests were added if applicable.
• CI passed.

Release Notes

Please follow release notes guidelines and fill in the release notes below.

 == RELEASE NOTES == =
Security Changes
* Upgrade okio to 3.6.0 in response to `CVE-2023-3635 <https://github.com/advisories/GHSA-w33c-445m-f8w7>`_. :pr:`23796`
* Upgrade okhttp to 4.12.0 in response to `CVE-2023-3635 <https://github.com/advisories/GHSA-w33c-445m-f8w7>`_.  :pr:`23796`

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: Mariamalmesfer / name: Mariam AlMesfer (4bbd3de)

[steveburnett]

Thanks for the release note entry! Nit to remove # from the PR number.

 == RELEASE NOTES == =

Security Changes
* Upgrade okio to 3.6.0 :pr:`23796`
* Upgrade okhttp to 4.12.0 :pr:`23796`

[arhimondr]

@Mariamalmesfer Please do not ignore depdendency conflicts. It causes problems in projects using various Presto libraries as a dependency.

[arhimondr]

#24459

[ZacBlanco]

We ignored this because OkHttp brings in two versions of this dependency. It seems to be entirely within the OkHttp libraries: #23796 (comment)

If our enforcer plugin complains about this, how would you fix it? It seems to be a problem with the upstream dependency and not something Presto should control.

[ZacBlanco]

It is a known issue upstream but they don't seem to plan on fixing it in the 4.x line. square/okhttp#8288 (comment)

[arhimondr]

In the runtime you cannot have two versions of the same class. At the end of the day the VM will have to pick one, possibly in a non deterministic way. Silencing the check doesn't make the problem go away. We need to pick a single version explicitly and exclude the other one to resolve the problem.

[arhimondr]

@ZacBlanco I looked at a problem a little bit more. As you mentioned it looks like okio-jvm depends on a different version of the kotlin-stdlib-jdk8 and the kotlin-stdlib-common libraries. okio-jvm depends on version 1.9.10 while the okhttp depends on 1.8.21.

Consider excluding kotlin-stdlib-jdk8, kotlin-stdlib-common from the okio-jvm in the dependency management section of the main pom:

            <dependency>
                <groupId>com.squareup.okio</groupId>
                <artifactId>okio-jvm</artifactId>
                <version>3.6.0</version>
                <exclusions>
                    <exclusion>
                        <groupId>org.jetbrains.kotlin</groupId>
                        <artifactId>kotlin-stdlib-jdk8</artifactId>
                    </exclusion>
                    <exclusion>
                        <groupId>org.jetbrains.kotlin</groupId>
                        <artifactId>kotlin-stdlib-common</artifactId>
                    </exclusion>
                </exclusions>
            </dependency>

And including this dependency in the presto-client/pom.xml:

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

Unfortunately once you do this the dependency checker complains that the okio-jvm is unused. However due to Kotlin quirks it has to stay in compile scope. To workaround that consider referencing a class from the okio-jvm in a Dummy class:

import okio.ByteString;

 public class Dummy
 {
    static {
        okio.ByteString byteString = new ByteString(new byte[] {});
        System.out.println(byteString);
    }
 }

This should hopefully resolve the conflict. This approach is better as it doesn't push the problem down to the presto-jdbc consumers.

Additionally you need to shade kotlin dependencies (kotlin.) as well as Jetbrains annotations (org.intellij., org.jetbrains.*) here to avoid class name conflicts in presto-jdbc.

[arhimondr]

What issue does this dependency cause? Is this dependency needed in runtime?

[Mariamalmesfer]

The exclusion prevents a build failure due to scope conflicts. Without it, Maven reports scope issues that lead to build failures. This dependency isn't needed at runtime; it's only required to pass the build checks.

[prestodb-ci]

@ethanyzhang imported this issue into IBM GitHub Enterprise