discord-jda/JDA

Update OkHttp dependency to avoid CVE-2020-29582, CVE-2020-15824 and CVE-2022-24329

mind-overflow opened this issue · 2 comments

mind-overflow commented

General Troubleshooting

  • I have checked for similar issues on the Issue-tracker.
  • I have updated to the latest JDA version
  • I have checked the branches or the maintainers' PRs for upcoming features.

Feature Request

Not a feature request, but I couldn't find a way to post a simple issue without using a form.

JDA depends on com.squareup.okhttp3:okhttp:4.9.3, which in turn depends on two vulnerable Kotlin libraries (kotlin-stdlib-common v1.4.0 and kotlin-stdlib v1.4.10). This is what the concerned Maven dependency tree looks like:

[INFO] +- net.dv8tion:JDA:jar:5.0.0-beta.2:compile
[INFO] |  +- com.squareup.okhttp3:okhttp:jar:4.9.3:compile
[INFO] |  |  +- com.squareup.okio:okio:jar:2.8.0:compile
[INFO] |  |  |  \- org.jetbrains.kotlin:kotlin-stdlib-common:jar:1.4.0:compile
[INFO] |  |  \- org.jetbrains.kotlin:kotlin-stdlib:jar:1.4.10:compile

There are also related issues on the OkHttp repository: square/okhttp#6219 and square/okhttp#7217

OkHttp doesn't seem to be affected by CVE-2020-15824 and CVE-2022-24329, as it doesn't rely on Kotlin scripting, but it still depends on the vulnerable libraries and is thus often detected as vulnerable by code analysis tools like SonarQube. CVE-2020-29582 might still apply.

image

Concerned issues: CVE-2020-29582 | CVE-2020-15824 | CVE-2022-24329

Updating the OkHttp dependency would prevent this from happening and fix the vulnerability.

MinnDevelopment commented

Thank you for the detailed report! I believe this should be resolved by #2382 and 5.0.0-beta.3.

mind-overflow commented

No problem, and thank you for the great work!
I tried JDA 5.0.0-beta.3 and it seems fixed - we're left with a false positive, but nothing else can be done until okhttp releases a new version.

The reason is that with v4.10.0 they changed their dependencies to this:

[INFO] +- net.dv8tion:JDA:jar:5.0.0-beta.3:compile
[INFO] |  +- com.squareup.okhttp3:okhttp:jar:4.10.0:compile
[INFO] |  |  +- com.squareup.okio:okio-jvm:jar:3.0.0:compile
[INFO] |  |  |  +- org.jetbrains.kotlin:kotlin-stdlib-jdk8:jar:1.5.31:compile
[INFO] |  |  |  |  \- org.jetbrains.kotlin:kotlin-stdlib-jdk7:jar:1.5.31:compile
[INFO] |  |  |  \- org.jetbrains.kotlin:kotlin-stdlib-common:jar:1.5.31:compile
[INFO] |  |  \- org.jetbrains.kotlin:kotlin-stdlib:jar:1.6.20:compile

So, while previously, okhttp v4.9.3 depended on com.squareup.okio:okio v2.8.0, newer okhttp v4.10.0 depends on com.squareup.okio:okio-jvm v3.0.0 which, now, imports the vulnerable org.jetbrains.kotlin:kotlin-stdlib-jdk8 v1.5.31 package (CVE-2022-24329). Funnily enough, the previous com.squareup.okio:okio package did not have this issue.

This is fixed in com.squareup.okio:okio-jvm v3.3.0 but there's currently no okhttp release that depends on that version. All other CVEs are now fixed.

Thank you again and sorry for stealing your time! I guess I'll ping the people over at okhttp, tho this is very minor as it's just a false positive.

  • 👍3