[SECURITY] 0.9.* Releases were built/executed/released in the context of insecure/untrusted code

[JLLeitschuh]

CWE-829: Inclusion of Functionality from Untrusted Control Sphere

All of these build files include resolving these 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 JAR files were compromised, any developers using these dependencies now could continue to be infected.

• https://github.com/ktorio/ktor/blob/0.9.5/build.gradle
• https://github.com/ktorio/ktor/blob/0.9.4/build.gradle
• https://github.com/ktorio/ktor/blob/0.9.3/build.gradle
• https://github.com/ktorio/ktor/blob/0.9.2/build.gradle
• https://github.com/ktorio/ktor/blob/0.9.1/build.gradle
• https://github.com/ktorio/ktor/blob/1.0.0/build.gradle
• https://github.com/ktorio/ktor/blob/1.0.1/build.gradle

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 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

[cy6erGn0m]

Well, these versions couldn't be entirely removed. However it's planned to remove these outdated versions anyway from project generator and apidoc website.

[cy6erGn0m]

Also these versions are not published to maven central but only to bintray. So it could be possible to overwrite pom files that is usually bad idea but could be possible. Not sure if we have to try it.

[JLLeitschuh]

It's also important to note that any developers using this repository during this development period could have their computers compromised and may still be compromised if they haven't reinstalled their OS.

I think it's probably sufficient to file for a CVE number (I can do this unless Jetbrains is a CNA and can get this done faster) and make a concerted effort to not ever execute those old tags on any developers machines.

I've also updated the issue to mention that versions 1.0.0 and 1.0.1 are also impacted by this.

[cy6erGn0m]

Sorry, now I don't get your point: no released pom file have this usafe http urls inside, current master branch don't have as well. We have http url in out git repository and these commit can't be removed. Why this issue is particular to ktor and what steps we can do to prevent user from using insecure connections?

[cy6erGn0m]

The only solution is to discard the whole bintray repo and make a new one with different name/url. Unfortunately this repo doesn't belong to ktor but to the big kotlin. Not sure if we can do this that easily.

[JLLeitschuh]

Sorry, now I don't get your point: no released pom file have this usafe http urls inside, current master branch don't have as well. We have http url in out git repository and these commit can't be removed. Why this issue is particular to ktor and what steps we can do to prevent user from using insecure connections?

This isn't a user issue, this is a developer issue and there was the potential for the build server that was used to build the Ktor releases to have been maliciously MITMed.

The fallout is if someone was attempting to maliciously compromise Ktor via a MITM, they've already done it.

[JLLeitschuh]

Related: ktorio/ktor-samples#40

[oleg-larshin]

Please check the following ticket on YouTrack for follow-ups to this issue. GitHub issues will be closed in the coming weeks.