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

[SECURITY] Releases are built/executed/released in the context of insecure/untrusted code #973

Closed
JLLeitschuh opened this issue Feb 25, 2019 · 5 comments

Comments

Projects
None yet
1 participant
@JLLeitschuh
Copy link

commented Feb 25, 2019

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

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 has existed since 2014 to maliciously compromise a JAR file inflight.
See:

MITM Attacks Increasingly Common

See:

Source Locations

maven {
url 'http://repo.spring.io/plugins-release'
}

Public Disclosure

Option 1: File for a CVE

A project maintainer for this project should probably file for a CVE number to inform the public about this vulnerability in the build for this project. The goal is to inform the public that there was a potential for published build artifacts to have been maliciously compromised in earlier releases.

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

Option 2: Manually validate the release artifacts

If this project's build is fully reproducible. An alternative to filing for a CVE is to go back and build the earlier releases (with the HTTPS patch applied) to confirm the artifacts were not tampered when they were built. This can be done by comparing the hashes of the artifacts built locally with the ones published. If the hashes of all previous artifacts match those that are published, you can safely assume that the releases were not tampered with.

Again, this assumes that the build if fully reproducible and will require significantly more work.

@JLLeitschuh

This comment has been minimized.

Copy link
Author

commented Apr 18, 2019

Ping! This is a security issue.

thekingnothing added a commit that referenced this issue Apr 21, 2019

@JLLeitschuh

This comment has been minimized.

Copy link
Author

commented Apr 22, 2019

This shouldn't be closed until the public disclosure issue is resolved.

@JLLeitschuh

This comment has been minimized.

Copy link
Author

commented May 3, 2019

Please re-open this issue until the public disclosure aspect is resolved.

This may help your team on your audit:
https://reproducible-builds.org/tools/

If there is no plan to perform an audit, I'll file for a CVE on June 1st, 2019.

@JLLeitschuh

This comment has been minimized.

Copy link
Author

commented May 16, 2019

Without a resolution by June 1st, I'll move forward with the CVE submission process.

@JLLeitschuh

This comment has been minimized.

Copy link
Author

commented May 23, 2019

@thekingnothing Ping ^^

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.