Community
Participate
Working Groups
The Che stacks build (https://github.com/eclipse/che-dockerfiles) have several Dockerfiles that pull down binaries over http. While unlikely, the risk here is that a motivated and skilled attacker could potentially man-in-the-middle the build process and inject custom, malicious code. As an example, here's the Dockerfile for alpine_jdk8 (https://github.com/eclipse/che-dockerfiles/blob/master/recipes/alpine_jdk8/Dockerfile): ``` wget -q "http://apache.ip-connect.vn.ua/maven/maven-3/$MAVEN_VERSION/binaries/apache-maven-$MAVEN_VERSION-bin.tar.gz" && \ ``` Ideally, the signatures for the build would be pulled down over https to verify the binaries. They are available here: https://www.apache.org/dist/maven/maven-3/3.3.9/binaries/apache-maven-3.3.9-bin.tar.gz.asc. Else, downloading directly from apache, which has a valid certificate, would be better: https://www.apache.org/dist/maven/maven-3/3.3.9/binaries/apache-maven-3.3.9-bin.tar.gz Here's the android stack (https://github.com/eclipse/che-dockerfiles/blob/master/recipes/android/Dockerfile): ``` wget --output-document=android-sdk.tgz --quiet http://dl.google.com/android/android-sdk_r24.4.1-linux.tgz ``` centos_jdk8: ``` wget -qO- "http://archive.apache.org/dist/tomcat/tomcat-8/v8.0.24/bin/apache-tomcat-8.0.24.tar.gz" | tar -zx --strip-components=1 -C /home/user/tomcat8 && \ ``` php: ``` wget http://repos.zend.com/zend-server/9.0.2/deb_apache2.4/pool/zend-server-php-7.0-common_9.0.2+b174_amd64.deb ``` and there are probably more.
The handbook provide guidance for handling vulnerability reports. https://www.eclipse.org/projects/handbook/#vulnerability
Thank you for reporting this issue Scott. We are not using the Dockerfiles in https://github.com/eclipse/che-dockerfiles since version 7.0.0 of Che (august this year). We are currently using the repositories in https://github.com/che-dockerfiles. We need to investigate if the vulnerability exist for the new Dockerfiles. From a first look it doesn't seam it's the case.
What is the status of this? Is a CVE for the affected versions required?
We never issued a CVE related to this issue. The mentioned repository is not used anymore but was used for Che 6.x releases.
(In reply to Mario Loriedo from comment #4) > We never issued a CVE related to this issue. The mentioned repository is not > used anymore but was used for Che 6.x releases. Does that mean that the vulnerability is in the 6.x releases? If yes, then my recommendation is that assign a CVE. I do, however, defer to your judgement. If you agree that we should assign a CVE, then please help me by providing a short write up and CWE. If you disagree, then please close this issue.
I do agree that we should create a CVE. I will provide you the required details tomorrow.
Project name: Eclipse Che Project id: ecd.che Versions affected: [6.x] Common Weakness Enumeration: - CWE-924: Improper Enforcement of Message Integrity During Transmission in a Communication Channel Summary: The build of some language stacks of Eclipse Che version 6 includes pulling some binaries from an unsecured HTTP endpoint. As a consequence the builds of such stacks are vulnerable to MITM attacks that allow the replacement of the original binaries with arbitrary ones. The stacks involved are Java 8 (alpine and centos), Android and PHP. The vulnerability is not exploitable at runtime but only when building Che. Links: - https://bugs.eclipse.org/bugs/show_bug.cgi?id=540989
I've created CVE-2021-41034. If we're done here, please resolve the issue as FIXED.
