[Bug 544852] Releases were & are built/executed/tested/released in the context of insecure/untrusted code
Bugzilla Link | 544852 |
Status | NEW |
Importance | P3 major |
Reported | Feb 26, 2019 17:41 EDT |
Modified | Jan 10, 2020 11:42 EDT |
See also | 546516, 546997, 547007, 547008 |
Reporter | Jonathan Leitschuh |
Description
Eclipse Security Team,
This email is to responsibly disclose a widespread security vulnerability in several of the Eclipse Repositories.
CWE-829: Inclusion of Functionality from Untrusted Control Sphere
CWE-494: Download of Code Without Integrity Check
If this vulnerability has been exploited by anyone, it could have massive downstream impacts on the rest of the Eclipse ecosystem.
Related issue: https://bugs.eclipse.org/bugs/show_bug.cgi?id=444350
Impact Locations\
I've been searching through GitHub repositories looking for places where build infrastructure (either Gradle, Maven, or other tools) are downloading code over HTTP and then executing it.
These are the locations that I found in your organization's builds:
XText-XTend:
Brit:
- https://github.com/eclipse/birt/blob/638a21a72f1c0b3695070f1dd2128723db6f502e/pom.xml#L28-L39\
- https://github.com/eclipse/birt/blob/638a21a72f1c0b3695070f1dd2128723db6f502e/pom.xml#L48-L59\
- https://github.com/eclipse/birt/blob/638a21a72f1c0b3695070f1dd2128723db6f502e/pom.xml#L68-L79
Orion:
Gef:
Sw360:\
- https://github.com/eclipse/sw360/blob/e06538b6461b0549002b45acec0b8b1333641063/rest/authorization-server/pom.xml#L137-L146\
- https://github.com/eclipse/sw360/blob/e06538b6461b0549002b45acec0b8b1333641063/rest/resource-server/pom.xml#L261-L270
Hawkbit:\
XText-Maven:\
Vorto:\
This is not a complete list. This is all I was able to find using a few simple search queries using GitHub's fuzzy search. I'm also not very good at looking at ANT buildscripts and determining if a specific URL is being used to resolve dependencies or not.
This wildcard query may help your team find more of these than I could report here:\
WARNING! If any of the Eclipse builds are using a shared ~/.gradle
or ~/.m2
cache between builds and any of these downloads were maliciously compromised, the compromised jar may remain inside of cache directory and continue to be used in the future.
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://thenextweb.com/insights/2017/12/11/comcast-continues-to-inject-its-own-code-into-websites-you-visit/\
https://serverfault.com/a/153065\
https://security.stackexchange.com/a/12050
Fix & Disclosure\
At a minimum, all of these code locations where artifacts are downloaded from an untrusted source needs to be fixed. I don't know what the Elastic team wants to do about versions that are already released.
Additionally, CVE numbers need to be issued for these vulnerabilities after they are responsibly fixed.
This responsible disclosure follows Google's 90-day vulnerability disclosure policy (I'm not an employee of Google, I just like their policy).
https://www.google.com/about/appsecurity/