是否可以从OkHttp解决org.jetbrains.kotlin:kotlin-stdlib的漏洞?

huangapple go评论58阅读模式
英文:

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

问题

我正在使用 Snyk 服务来检查我的项目是否存在漏洞。

具有 OkHttp 依赖项的项目具有一个常见的漏洞:

受影响的模块: org.jetbrains.kotlin:kotlin-stdlib
通过以下方式引入: com.squareup.okhttp3:okhttp@4.10.0

您可以在此处查看完整报告:https://snyk.io/test/github/yvasyliev/deezer-api

概述 部分有一条注释:
> 注意:从版本1.4.21开始,已将有漏洞的函数标记为弃用。由于仍然可用,此建议被保留为“未修复”。

我有两个问题:

  1. 我可以在 Maven 项目中修复这个漏洞吗,如何修复?
  2. 如果漏洞无法修复,那么是否意味着每个 Kotlin 应用程序默认都存在此漏洞(因为它来自 kotlin-stdlib)?

OkHttp 项目中添加的最新稳定版本为 Maven

<dependency>
    <groupId>com.squareup.okhttp3</groupId>
    <artifactId>okhttp</artifactId>
    <version>4.10.0</version>
</dependency>
英文:

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>

答案1

得分: 2

以下是翻译好的内容:

"Details on the vulnerability are listed in your Snyk report.":
"漏洞的详细信息在您的 Snyk 报告中列出。"

"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.":
"存在问题的函数是来自 kotlin.io 包的 createTempDircreateTempFile。正如您的报告以及 Kotlin 文档 中所概述的,这些函数可能是信息泄漏的潜在来源,因为创建的文件/目录具有过于宽松的权限,也就是说,拥有文件系统访问权限的任何人都可以读取这些文件。"

"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:":
"为了直接回答您的问题:"

"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 no one is using the functions and you're not affected anyway.":
"不幸的是,没有容易的方法来修复这个问题。您要么必须使用尚未引入该函数的 kotlin-stdlib 版本,要么完全从您的类路径中排除 kotlin-stdlib,或者使用不再包含这些函数的版本;但这个版本尚未发布。然而,选项 1 和 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.":
"不是和是。依赖于受影响版本中的 kotlin-stdlib 的每个人都在其类路径上有该函数。然而,只要它没有被使用,或者使用不会引起上述问题,那么软件就不会受到威胁。"

英文:

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.

huangapple
  • 本文由 发表于 2023年2月17日 23:53:17
  • 转载请务必保留本文链接:https://go.coder-hub.com/75486505.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定