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

[JLLeitschuh]

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:

• https://max.computer/blog/how-to-take-over-the-computer-of-any-java-or-clojure-or-scala-developer/
• https://github.com/mveytsman/dilettante

MITM Attacks Increasingly Common

See:

• https://serverfault.com/a/153065
• https://security.stackexchange.com/a/12050

Source Locations

• grails-core/build.gradle

  Line 5 in 92304cb

  maven { url 'http://dl.bintray.com/vermeulen-mp/gradle-plugins' }

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]

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]

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]

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]

Demonstration of attack via a MITM:

• https://max.computer/blog/how-to-take-over-the-computer-of-any-java-or-clojure-or-scala-developer/
• https://github.com/mveytsman/dilettante

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

[JLLeitschuh]

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:

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

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

• https://github.com/issues?utf8=%E2%9C%93&q=author%3AJLLeitschuh+archived%3Afalse+sort%3Aupdated-desc+%5BSECURITY%5D+

[graemerocher]

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]

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

[graemerocher]

Will do

[JLLeitschuh]

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

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

[graemerocher]

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]

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

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

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

gradle/gradle#9419

[ilopmar]

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]

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

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

[ilopmar]

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

[ilopmar]

@JLLeitschuh The CVE is published: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12728

[JLLeitschuh]

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

[rahulagrawal]

I was reading this - https://maven.apache.org/docs/3.8.1/release-notes.html#the-detailed-issue-list
Where by default http is blocked starting with maven 3.8.1.
My question is that if a local project is using maven 3.8.1 or higher and the latest and greatest version of java 8, will that technically be enough to get the confidence that the above issue of man in the middle attack is ruled out.
The reason for asking this on a closed thread is because I have to maintain a legacy application and I need to guard it also.