Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG][SECURITY][CVE-2019-11405] Code generator generates projects with insecure repositories #2253

Closed
JLLeitschuh opened this issue Feb 27, 2019 · 7 comments
Milestone

Comments

@JLLeitschuh
Copy link
Contributor

JLLeitschuh commented Feb 27, 2019

CWE-829: Inclusion of Functionality from Untrusted Control Sphere
CWE-494: Download of Code Without Integrity Check

This project is generating starter projects that are resolving dependencies over HTTP instead of HTTPS.

Additionally, the sample associated with this project are vulnerable to this as well. 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 has existed since 2014 to maliciously compromise a JAR file inflight.
See:

MITM Attacks Increasingly Common

See:

Source Locations

repositories {
maven { url 'http://repo.jfrog.org/artifactory/gradle-plugins' }
}

mavenCentral(artifactUrls: ['http://maven.springframework.org/milestone'])
maven { url "http://$artifactory:8080/artifactory/repo" }

maven { url "http://dl.bintray.com/kotlin/ktor" }
maven { url "https://dl.bintray.com/kotlin/kotlinx" }

There are definitely more locations that I've listed here. I know that @wing328 has caught many of them here #2248. I just ask that the team take an extra sweep to check for this anywhere else and be aware of it in future PR's.

Public Disclosure

This issue requires public disclosure as it impacts users that have used this project to generate their starter projects.

A project maintainer needs to file for a CVE number to inform the public about this vulnerability.

If a maintainer on this project works for or is associated with a CNA, please have them file it with them:
cve.mitre.org/cve/request_id.html

Otherwise, an open source CVE should be filed for here:
iwantacve.org

@wing328
Copy link
Member

wing328 commented Feb 27, 2019

@JLLeitschuh thanks for reporting the issue. I've filed a PR (#2248) to update those URLs to use https instead of http

@JLLeitschuh JLLeitschuh changed the title [BUG] Code generator generates projects with insecure repositories [BUG][SECURITY] Code generator generates projects with insecure repositories Apr 18, 2019
@JLLeitschuh
Copy link
Contributor Author

JLLeitschuh commented Apr 18, 2019

Hey @wing328

I just found more examples:

resolvers += "TM" at "http://maven.twttr.com"
resolvers += "Local Maven Repository" at "file://"+Path.userHome.absolutePath+"/.m2/repository"
resolvers += "Sonatype OSS Snapshots" at "http://oss.sonatype.org/content/repositories/snapshots/"
resolvers += "Sonatype OSS Releases" at "http://oss.sonatype.org/content/repositories/releases/"

What is our public disclosure plan on this? Am I filing for the CVE number or will you?

@wing328
Copy link
Member

wing328 commented Apr 19, 2019

I've filed #2697 to update the samples.

Please file the CVE as I'm not familiar with the procedure.

@JLLeitschuh
Copy link
Contributor Author

JLLeitschuh commented Apr 19, 2019

@wing328 There may be issues with Java 6 not supporting certain TLS algorithms that maven central requires.

You may straight up not be able to support Java 6 with HTTPS for JCenter. I don't know.

Related scala/sbt-scala-module#41

Also, what version is this officially fixed in for the CVE writeup.

@JLLeitschuh JLLeitschuh changed the title [BUG][SECURITY] Code generator generates projects with insecure repositories [BUG][SECURITY][CVE-2019-11405] Code generator generates projects with insecure repositories Apr 22, 2019
@JLLeitschuh
Copy link
Contributor Author

JLLeitschuh commented Apr 22, 2019

The CVE number has been issued for this vulnerability.

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

This is the current description:

OpenAPI Tools OpenAPI Generator before 4.0.0-20190419.052012-560 uses http:// URLs in various build.gradle, build.gradle.mustache, and build.sbt files, which may have caused insecurely resolved dependencies.

I've asked the CVE team to update the description to better reflect how this impacts downstream users.

I think the way it's currently stated, it implies that this may have impacted the OpenAPI's releases. Instead, it needs to reflect how this impacts users who are using this project to generate code and may be impacted.

@wing328 wing328 modified the milestones: 4.0.0, 4.0.1 May 13, 2019
@wing328 wing328 modified the milestones: 4.0.1, 4.0.2 May 31, 2019
@jmini
Copy link
Member

jmini commented Jun 12, 2019

@JLLeitschuh: This is an interesting finding. Thank you for the analysis and the report.

The 2 PRs filed to fix this only changes stuff to our samples or templates. This means that prior this version, if you were generating projects with OpenAPI-Generator then you could end up with a pom/gradle/sbt file referencing a http repository.

For our own binaries, hosted under http://central.maven.org/maven2/org/openapitools/ it seems to me that our poms (and gradle file for the gradle plugin) are using https repositories.

@JLLeitschuh
Copy link
Contributor Author

The 2 PRs filed to fix this only changes stuff to our samples or templates. This means that prior this version, if you were generating projects with OpenAPI-Generator then you could end up with a pom/gradle/sbt file referencing a http repository.

Correct, hence the CVE number.

This should be resolved now. It's been a pleasure working with @wing328 on this. Here's my publication about this industry-wide vulnerability:

mitm_build
Want to take over the Java ecosystem? All you need is a MITM!

@jmini jmini closed this as completed Jun 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants