javamavenkotlinokhttpsnyk

Is it possible to solve org.jetbrains.kotlin:kotlin-stdlib vulnerability from OkHttp?

I'm using Snyk service to check my projects for vulnerabilities.

Projects with OkHttp dependency have one common vulnerability:

Vulnerable module: org.jetbrains.kotlin:kotlin-stdlib
Introduced through: com.squareup.okhttp3:okhttp@4.10.0

You can check the full report here: https://snyk.io/test/github/yvasyliev/deezer-api

In Overview section there is a note:

Note: As of version 1.4.21, the vulnerable functions have been marked as deprecated. Due to still being useable, this advisory is kept as "unfixed".

I have two questions:

  1. Can I fix this vulnerability in Maven project and how?
  2. If vulnerability cannot be fixed, then does it mean that every signle Kotlin application has this vulnerability by default (since it's comming from kotlin-stdlib)?

The latest stable version of OkHttp is added to project by Maven:

<dependency>
    <groupId>com.squareup.okhttp3</groupId>
    <artifactId>okhttp</artifactId>
    <version>4.10.0</version>
</dependency>
Solution

  • As with all vulnerable software libraries, you need to assess whether or not you're actually affected by the vulnerability that is included.

    Details on the vulnerability are listed in your Snyk report. The problematic functions are createTempDir and createTempFile from the package kotlin.io. As outlined in your report as well as the Kotlin documentation, these functions are a possible source of leaking information, due to the created file / directory having having too wide permissions; that is, everyone with access to the file system can read the files.

    Is this a problem?
    If you (and any dependencies you're including in your software) is NOT using one of the aforementioned functions, you're not vulnerable.
    Also, if you (or the dependency) is adjusting the file permissions after calling one of these functions and before inserting any information, you're not affected.
    In case the functions are used and the permissions are not adjusted, still that might not pose a problem, as long as the data stored in the files do not need to be protected, e.g. are NOT secrets or personal information.

    To address your questions directly:

    1. Unfortunately, there is not easy way to fix this. You either would have to use a version of kotlin-stdlib where the function was not introduced yet, exclude the kotlin-stdlib from your classpath entirely or use a version where the functions are no longer included; which is not released yet. However, options 1 and 2 do not make any sense, because if the software keeps working, that means noone is using the functions and you're not affected anyway.
    2. No and yes. Everyone relying on the kotlin-stdlib in one of the affected versions, has the function on its classpath. However, as long as it is not used, or the usage does not pose a problem as explained above, the software is not vulnerable.

    The OkHttp project seems to know of the vulnerability, but seems not to be affected.