Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
[CVE-2019-10249][SECURITY] Releases are built/executed/released in the context of insecure/untrusted code #759
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
This isn't just theoretical
POC code has existed since 2014 to maliciously compromise a JAR file inflight.
MITM Attacks Increasingly Common
This was originally responsibly disclosed privately, but I was asked to make it public by @waynebeaton.
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:
Otherwise, an open source CVE should be filed for here:
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.
@waynebeaton @JLLeitschuh i find this strange.
created https://bugs.eclipse.org/bugs/show_bug.cgi?id=546996 for CVE
The link to the handbook provides information on how to actually engage the security team in this process.
I only respond to requests for CVEs from project committers. Further, as described in that handbook link, the bug needs to be closed as FIXED and the committers-only flag removed. The existing Bug 544852 serves well as further background and should be used for the request.
I'm already in copy, so I'll probably notice when this happens, but a quick note to the security team (which I see that you've already sent) makes sure that our security-minded folks are all in the loop.
changed the title
[SECURITY] Releases are built/executed/released in the context of insecure/untrusted code
May 6, 2019
I was explicitly asked to open this publicly. My original intention was to keep it private. You can see the discussion in the original bug chain: https://bugs.eclipse.org/bugs/show_bug.cgi?id=544852