[CVE-2019-11404][SECURITY] Releases are built/executed/released in the context of insecure/untrusted code

[JLLeitschuh]

CWE-829: Inclusion of Functionality from Untrusted Control Sphere

The build files indicate that this project is resolving dependencies over HTTP instead of HTTPS. Any of these artifacts could have been MITM to maliciously compromise them and infect the build artifacts that were produced. Additionally, if any of these JARs or other dependencies were compromised, any developers using these could continue to be infected past updating to fix this.

This vulnerability has a CVSS v3.0 Base Score of 8.1/10
https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

This isn't just theoretical

POC code exists already to maliciously compromise a JAR file inflight.
See:

• https://max.computer/blog/how-to-take-over-the-computer-of-any-java-or-clojure-or-scala-developer/
• https://github.com/mveytsman/dilettante

MITM Attacks Increasingly Common

See:

• https://serverfault.com/a/153065
• https://security.stackexchange.com/a/12050

Source Locations

arrow/build.gradle

Line 42 in b789243

maven { url "http://dl.bintray.com/kotlin/kotlin-dev" }

arrow/build.gradle

Lines 72 to 73 in b789243

	maven { url "http://dl.bintray.com/kotlin/kotlin-dev" }
	maven { url "http://dl.bintray.com/arrow-kt/arrow-kt" }

[pakoito]

Fixed on master in 74198da. Thanks for the heads-up @JLLeitschuh !!!

[JLLeitschuh]

@pakoito Should a CVE be issued for earlier versions of Arrow as they could have been compromised? This is a non-issue if your builds are fully reproducible and you can prove that previous releases weren't compromised as the hashes match.

[pakoito]

I am not familiar with any of the security procedures you've just mentioned. The dependencies seem to be used for pre-release versions of Kotlin and Arrow, which makes the set of vulnerable versions limited to SNAPSHOTS and binaries such as Ank.

[JLLeitschuh]

The dependencies seem to be used for pre-release versions of Kotlin and Arrow, which makes the set of vulnerable versions limited to SNAPSHOTS and binaries such as Ank.

When Gradle downloads artifacts, they are stored in the ~/.gradle directory.
So if a pre-release and a release use the same artifact, then the pre-release one could be used.

Also, depending upon where the MITM is occurring, the repository requests that are higher in the list could have been intentionally blocked to force the build to try the insecure repository.

I am not familiar with any of the security procedures you've just mentioned.

CVE stands for Common Vulnerabilities and Exposures. It is a program launched in 1999 by MITRE, a nonprofit that operates research and development centers sponsored by the federal government, to identify and catalog vulnerabilities in software or firmware into a free “dictionary” for organizations to improve their security.
- https://www.csoonline.com/article/3204884/application-security/what-is-cve-its-definition-and-purpose.html

You can file for a CVE here:
https://iwantacve.org/

If anyone who is a part of the arrow organization works for a CNA they can file for a CVE faster through them. Here is the CNA list:
https://cve.mitre.org/cve/request_id.html

[pakoito]

CI builds our artifacts from scratch, spinning up a new image for each and re-downloading the dependencies. There's no caching involved, so there's none of those risks. Our dependencies are also pinned to a specific version, with pre-releases clearly suffixed "-rc" or similar.

[pakoito]

I'm not for opening a CVE, maybe @raulraja feels otherwise.

[raulraja]

@pakoito I'm not opposed to a CVE, but also not interested in going through the trouble given you already addressed those concerns with your comments.

[JLLeitschuh]

CI builds our artifacts from scratch, spinning up a new image for each and re-downloading the dependencies. There's no caching involved, so there's none of those risks. Our dependencies are also pinned to a specific version, with pre-releases clearly suffixed "-rc" or similar.

You're probably fine then. Thank you all.

[JLLeitschuh]

You're probably fine then. Thank you all.

I'm sorry, but I need to take this back. This probably does need a CVE assigned to it. I'm happy to file if you need me to.

Since the Kotlin compiler is downloaded insecurely, it could have been used to maliciously compromise the released build artifacts.

Given that repositories are resolved in the order they are listed, the insecure repository had the chance to be used to resolve various artifacts insecurely, thus exposing the arrow-kt releases to untrusted code.

Here's a similar CVE for Eclipse hawkBit that was requested by Wayne Beaton of the Eclipse Security Team due to my discovering this vulnerability in several of the Eclipse repositories.
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10240

[pakoito]

Go for it

[JLLeitschuh]

@pakoito Just a heads up, you don't have version 0.9.0 published to Maven central yet.

https://search.maven.org/artifact/io.arrow-kt/arrow-core/0.8.2/jar

[raulraja]

https://search.maven.org/search?q=a:arrow-core-data

[JLLeitschuh]

@raulraja Was there a rename?

This is the library list I'm looking at:
https://mvnrepository.com/artifact/io.arrow-kt

Also, you have another project vulnerable:

https://github.com/arrow-kt/arrow-collections/blob/1a04b24e8cde729c7fe1a74aba3c8bbe35b8174e/build.gradle#L39

[JLLeitschuh]

I've filed for the CVE numbers. Will update this issue when I have them.

[raulraja]

There was a rename of artifacts before 0.9.0 but the group-id is the same. arrow-core is now arrow-core-data for example.

[JLLeitschuh]

The CVE number for the vulnerability has been assigned.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11404

[JLLeitschuh]

As the CVE is now filed, I'm going to consider this issue closed, pleasure working with all of you.

[pakoito]

Thank you for doing due diligence on this topic.