Does anyone have any additional information about the Kotlin vulnerability reported in the <Q4 2020 ...

# android

[andreasmattsson]

Does anyone have any additional information about the Kotlin vulnerability reported in the Q4 2020 Security Bulletin?

We have developed an Android app for a client, and as part of security verification need to run a OWASP dependency check, and the only thing that came back flagged that appears on our app's runtime dependencies is CVE-2020-29582.

Unfortunately there is very little information on this, and the referenced issue KT-42181 is either private or unexistent.

[andreasmattsson]

It would be nice verify if this issue is actually applicable to our app (and other Android apps), and if there are any mitigations or fixes that can be applied beyond upgrading to a later Kotlin runtime?

Upgrading the Kotlin runtime is on our roadmap, but unfortunately we have custom code generation logic dependent on Kotlin internal serialization behavior that has changed between major releases. So in our cases that is a nontrivial thing to do, and we would hope to get this app accepted and released before that.

[ephemient]

the reporter @jlleitschuh is here, fyi

[ephemient]

I have no details but in general, these filesystem issues are only vulnerable when there are other programs outside your control with concurrent access to the same location that you are working in, which is rarely ever the case on Android

[jlleitschuh]

I agree with your sentiment. I've complained to JetBrains about this in the past. They do a really terrible job at disclosing vulnerabilities fully.

[jlleitschuh]

Give me a second, I'll publish my own disclosure RE this issue

[jlleitschuh]

The same vulnerability exists in Google Guava. The Google team deprecated the method instead of fixing it.

[jlleitschuh]

The Jetbrains team did the same thing here

[jlleitschuh]

Here's the published disclosure for that: https://github.com/JLLeitschuh/security-research/security/advisories/GHSA-5w9v-8x7x-rfqm

[andreasmattsson]

Thank you so much @jlleitschuh, that is immensely helpful to us!

[jlleitschuh]

If it's relevant, here's the same issue in Google Guava:
https://github.com/google/guava/issues/4011

[andreasmattsson]

Thank you too @ephemient, I suspected as much, that the types of file system operations involved would be unlikely to impact Android apps with any "normal" API usage. But I was beginning to lose any hope of being able to confirm it.

[jlleitschuh]

Depends what versions of android you are using

[jlleitschuh]

There's a long thread about the impact of this kind of vulnerability potentially on android here:

https://github.com/google/guava/issues/4011#issuecomment-769975829

[jlleitschuh]

Here you go: https://github.com/google/guava/issues/4011#issuecomment-772892561

[ephemient]

thanks for the additional information. minSdk=18 covers ~99.5% of active devices so I think my prior statement "rarely ever the case on Android" can be justified 🙂

[andreasmattsson]

Are you aware of any Kotlin API or functionality @jlleitschuh that make use of any of those methods internally? We don't make use of any Kotlin stdlib file operations at runtime in our app, but I guess we should make doubly sure none of our library dependencies do either.

(we have minSdk 23, and target/compile sdk 30, if it matters)

[jlleitschuh]

Not an android developer, most of those things don't mean much to me unfortunately. I rely upon others for information RE android

[andreasmattsson]

Okay. It's getting late here, but I'll definitely be diving deeper into those links tomorrow. Thanks again for providing me a good starting point!

[jlleitschuh]

From @ilya.gorbunov in the private discusson on that issue:

> We'll however investigate whether these functions were used in the Kotlin codebase and issue a CVE if we find those places vulnerable.

Just a heads-up: we've fixed usages of these functions in the Kotlin codebase and shipped this change with Kotlin 1.4.21. Now we're waiting for a CVE number to be assigned.

Link not public, but anyone from Jetbrains who's curious and wants to refresh their memory:
https://youtrack.jetbrains.com/issue/KT-42181#focus=Comments-27-4614214.0-0

[jlleitschuh]

So, it looks like those methods were in use other places, but they never explicitly communicated which methods were impacted to me

[jlleitschuh]

If you have additional information you dig up, I'm happy to add it to my advisory

[andreasmattsson]

If I find anything I'll make sure to report back. But yeah, better still would be if JetBrains themselves were more forthright in their communication about this sort of thing.

[andreasmattsson]

A quick cursory glance using the built in IntelliJ code usage tools indicates our project has usages of that method at compile time via the Kotlin Gradle DSL, but I find nothing using those methods in the normal runtime stdlib. Probably not applicable to the android versions we target anyway, but feels better still if we don't touch any affected APIs at all. May also add a ArchUnit test as well as you suggested in that thread.

[jlleitschuh]

On older versions of Gradle, that vulnerability existed in Gradle itself because of it's own use of the system temporary directory:

https://github.com/gradle/gradle/security/advisories/GHSA-89qm-pxvm-p336

[jlleitschuh]

Not a huge risk assuming you're all running your Gradle builds on systems that don't have multiple users