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

Closed
JLLeitschuh opened this issue Feb 19, 2019 · 20 comments

Comments

Projects
None yet
3 participants
@JLLeitschuh
Copy link

commented Feb 19, 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

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.

@graemerocher

This comment has been minimized.

Copy link
Member

commented Feb 20, 2019

the repository in question is only used to resolve the sdkman notification service and not for any project dependencies. It is not used at any point during the construction of the binary and in fact for the last release failed to work anyway. Either step is not necessary since the repository in question doesn't include anything that is involved in the construction or publishing of the binary release artifacts

We will however change to use HTTPs and thanks for the report.

@JLLeitschuh

This comment has been minimized.

Copy link
Author

commented Feb 20, 2019

the repository in question is only used to resolve the sdkman notification service and not for any project dependencies. It is not used at any point during the construction of the binary and in fact for the last release failed to work anyway.

It doesn't matter what phase of the build the dependencies that are loaded over HTTP for. If at any point insecure code is loaded onto the classpath in the same environment where releases are produced, there is a potential for compromise.

Even if this vulnerability existed only in the tests, a malicious attacker still has remote code execution on the build server being used to create the artifacts for grails-core. The context where this is happening (build, test, or production artifact) doesn't really matter.

@graemerocher

This comment has been minimized.

Copy link
Member

commented Feb 20, 2019

Ok, if you can demonstrate a validated attack against the build then we will report a CVE, in the meantime I will verify the latest binary.

@JLLeitschuh

This comment has been minimized.

Copy link
Author

commented Feb 20, 2019

Demonstration of attack via a MITM:

If you're looking for something more, please elaborate.

@JLLeitschuh

This comment has been minimized.

Copy link
Author

commented May 3, 2019

Something that may help out with the auditing process:

https://reproducible-builds.org/tools/

If the decision is to not perform an audit, I'm happy to file the CVE request myself. If no audit is complete by June 1st, 2019, I'll move forward with the CVE process.

Here are the CVE numbers that have since been successfully filed with respect to this same vulnerability:

There are more to come (see my recent research):

@graemerocher

This comment has been minimized.

Copy link
Member

commented May 6, 2019

We are undertaking an audit, it will take some time. If you wish to file a CVE yourself that is completely up to you of course.

@JLLeitschuh

This comment has been minimized.

Copy link
Author

commented May 6, 2019

@graemerocher Please just update me by June 1st, 2019. Publication date about this in a wider context will be June 10th, 2019.

@graemerocher

This comment has been minimized.

Copy link
Member

commented May 6, 2019

Will do

@JLLeitschuh

This comment has been minimized.

Copy link
Author

commented May 6, 2019

@graemerocher Just a warning from those who have had to do this investigation before:

you need to know the JDK that built the jar to ensure the bytecode is the same. There are also some areas where the bytecode changes regardless of the JDK. For example, Groovy inserts date information into the .class file.

Hope this helps.

@JLLeitschuh

This comment has been minimized.

Copy link
Author

commented May 23, 2019

Friendly heads up that without an audit, a CVE number will be issued on June 1st, 2019.

@graemerocher

This comment has been minimized.

Copy link
Member

commented May 23, 2019

Yup, we have conducted the audit and the latest versions of the Grails 3.1.x, 3.2.x, 3.3.x and 4.x line contain no manipulated executable content. We undertook the same process as the Groovy team and diffed all jars and executable content. There were 6 differences in the generated byte code which we isolated to an issue in the Groovy compiler which was simply changing the order of the byte code output, but the byte code was the same.

In addition we have released Grails 3.3.10 which includes the applied patch and also a version of Groovy that also has the patch applied.

We will be reporting a CVE this week or early next.

@JLLeitschuh

This comment has been minimized.

Copy link
Author

commented May 23, 2019

@graemerocher Thanks for the update! And thanks for doing the audit!

If you want to get really fancy, you can use the new GitHub 'Maintainer Security Advisories' feature.

https://github.blog/2019-05-23-introducing-new-ways-to-keep-your-code-secure/#open-source-security

@graemerocher

This comment has been minimized.

Copy link
Member

commented May 23, 2019

@JLLeitschuh Thanks for the tip, btw we have also updated our builds to prevent regression:

https://github.com/grails/grails-core/blob/master/build.gradle#L597

@JLLeitschuh

This comment has been minimized.

Copy link
Author

commented May 23, 2019

🎉 I'm working on officially deprecating the security vulnerability in Gradle.

gradle/gradle#9419

@ilopmar

This comment has been minimized.

Copy link
Member

commented May 30, 2019

I've submitted the CVE request. I will update this issue once it's approved and the CVE number is assigned.
In the mean time you can follow the progress here: https://docs.google.com/spreadsheets/d/1PlDOsZ4Q36JU4Dz9zyBB2F3814dScppCRCe1muCT7JI/edit#gid=1009122160 (row 42 at this moment)

@JLLeitschuh

This comment has been minimized.

Copy link
Author

commented May 30, 2019

@ilopmar Just a heads up, the DFW has shut down so I don't know if that form is still checked.

https://twitter.com/kurtseifried/status/1103858442479910913

If you don't hear back in a few days, consider re-filing with the MITRE form.

@ilopmar

This comment has been minimized.

Copy link
Member

commented May 30, 2019

Thanks for the information. I'll keep you posted.

@ilopmar

This comment has been minimized.

Copy link
Member

commented Jun 4, 2019

@JLLeitschuh I've re-submitted the CVE in https://cveform.mitre.org/

@ilopmar

This comment has been minimized.

Copy link
Member

commented Jun 5, 2019

@ilopmar ilopmar closed this Jun 5, 2019

@JLLeitschuh

This comment has been minimized.

Copy link
Author

commented Jun 5, 2019

Thanks! Cheers! I'll post a link to my research when it goes public on June 10th, 2019.

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.