okhttp High Security Vulnerability in kubernetes-client 5.12.2

[jbusche]

trafficstars

Describe the bug

We're utilizing the Fabric8 kubernetes-client 5.12.2 in our Flink Kubernetes Operator here But we've found a vulnerability in the okhttp version:

cvss: 7.5
riskFactors: Has fix,High severity
cve: PRISMA-2022-0239    
link: https://github.com/square/okhttp/issues/6738
status: fixed in 4.9.2
description: com.squareup.okhttp3_okhttp packages prior to version 4.9.2 are vulnerable for sensitive information disclosure. An illegal character in a header value will cause IllegalArgumentException which will include full header value. This applies to Authorization, Cookie, Proxy-Authorization and Set-Cookie headers. 

@mbalassi noticed that even your latest v6.0.0-RC1 still has the older okhttp version here: https://github.com/fabric8io/kubernetes-client/blob/v6.0.0-RC1/pom.xml#L84

Is this relevant? Is it possible to bump the okhttp version to 4.9.2?

Alternatively, there's a discussion here https://github.com/fabric8io/kubernetes-client/issues/2764 that would ultimately bump the okhttp version to 4.9.x and might solve the problem as well.

Thanks

Fabric8 Kubernetes Client version

5.12.2

Steps to reproduce

Using twistlock security scan of our operator image, we're seeing a security vulnerability against the older okhttp version utilized.

"scanTime","scanID","scanVersion","scanConsole","scanIntelligenceTime","image","registry","repository","tag","digest","twistlockImageID","osDistro","osDistroRelease","osDistroVersion","architecture","size","hostname","issueType","severity","severityCHML","cvss","riskFactors","cve","link","hasFix","status","packageType","packageName","packageVersion","packageLicense","packageBinaryPkgs","packagePath","description","title","cause","complianceID"
"2022-07-20T23:05:10.811Z","62d88a262a196130ec8ff96d","21.08.514","sc-public-5.cp-cts-twistlock.svc.cluster.local:8183","2022-07-20T15:46:01.789Z","ghcr.io/apache/flink-kubernetes-operator:c9dec3f","ghcr.io","apache/flink-kubernetes-operator","c9dec3f","sha256:fa4f2dfd0f659b06876f1b4299d8af503035bf351c5660892d6e4a63ab6182d7","sha256:d58a28eb52c3f16cc0ea6488033198dbcd1efc512f21cf54f37e540cacb20e81","debian","bullseye","11.4","amd64","583372402","a9cc34b24850","vulnerability","high","H","7.5","Has fix,High severity","PRISMA-2022-0239","https://github.com/square/okhttp/issues/6738","Y","fixed in 4.9.2","jar","com.squareup.okhttp3_okhttp","3.12.12","","","/flink-kubernetes-operator/flink-kubernetes-operator-1.1.0-shaded.jar","com.squareup.okhttp3_okhttp packages prior to version 4.9.2 are vulnerable for sensitive information disclosure. An illegal character in a header value will cause IllegalArgumentException which will include full header value. This applies to Authorization, Cookie, Proxy-Authorization and Set-Cookie headers. ","","",""

Expected behavior

Expected the scan to be clean of vulnerabilities

Runtime

OpenShift

Kubernetes API Server version

1.22

Environment

Linux

Fabric8 Kubernetes Client Logs

No response

Additional context

No response

[manusa]

Context

The client uses OkHttp version 3.12.12 both in 5.12 and in the newer 6.0.0 version by default.

We've had many discussions about bumping the OkHttp client to 4 (#2764, #2632), but due to the introduction of Kotlin specific dependencies, we decided to remain on version 3. However, you can configure your project to use a different OkHttp version that the one we provide. In the Using a different OkHttp version with the client section I provide more details.

We've done a lot of work in version 6 to be able to decouple OkHttp completely from the project and be able to provide alternate HTTP client implementations. In version 6.0.0 we already introduced two new options, but more are coming.

Using a different OkHttp version with the client

Newer OkHttp versions (4) should be binary backwards compatible with OkHttp 3.

In scope of #2632, we documented how you can achieve this in your project https://github.com/fabric8io/kubernetes-client/issues/2632#issuecomment-880089245. So you should be able to follow this procedure for any Fabric8 Kubernetes Client version.

• Using KubernetesClient with IPv6 based Kubernetes Clusters

HTTP clients in version 6+

Starting from version 6 we provide additional HTTP client implementations which you can use instead of OkHttp. So far we've implemented a vanilla JDK HTTP client, and an Eclipse Jetty based client. However, both of this clients require JDK 11+.

We will keep providing more client implementations. Next up is Vert.x. We'll probably implement an additional HTTP client based on OkHttp 4 too.

Proposed solutions for Apache Flink

The easiest solution for you right now is to override the OkHttp client version. This should be a very easy change (just a few lines in your pom.xml file).

I see your project is based on Java 11. If you're upgrading to version 6 of the client, then you should also be able to try the other HTTP client implementations. Beware that these haven't been battle-tested yet.

[csviri]

For Java Operator SDK created PR: https://github.com/java-operator-sdk/java-operator-sdk/pull/1361

This is fixing the issues, in terms that all okhttp dependencies are now on version 4.10.0.

[stale[bot]]

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!