Closed JLLeitschuh closed 5 years ago
@JLLeitschuh thanks for reporting the issue. I've filed a PR (https://github.com/OpenAPITools/openapi-generator/pull/2248) to update those URLs to use https instead of http
Hey @wing328
I just found more examples:
What is our public disclosure plan on this? Am I filing for the CVE number or will you?
I've filed https://github.com/OpenAPITools/openapi-generator/pull/2697 to update the samples.
Please file the CVE as I'm not familiar with the procedure.
@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 https://github.com/scala/sbt-scala-module/issues/41
Also, what version is this officially fixed in for the CVE writeup.
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.
@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.
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:
Want to take over the Java ecosystem? All you need is a MITM!
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
https://github.com/OpenAPITools/openapi-generator/blob/c1afba71940ace713b3a88d472d1798a6e0d661a/modules/openapi-generator/src/main/resources/Groovy/build.gradle.mustache#L11-L13
https://github.com/OpenAPITools/openapi-generator/blob/c1afba71940ace713b3a88d472d1798a6e0d661a/modules/openapi-generator/src/main/resources/Groovy/build.gradle.mustache#L22-L23
https://github.com/OpenAPITools/openapi-generator/blob/0eb385c0d6497c38c09b42158b2d66109b78b15b/modules/openapi-generator/src/main/resources/kotlin-server/libraries/ktor/build.gradle.mustache#L60-L61
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