该漏洞允许远程网站在用户访问网页时，在运行早于 7.3.0 和 7.4.1 版本的 Che 的机器上创建并启动任意 docker 容器。
这是一个 CSRF 漏洞，允许远程网站在任何以独立模式运行 Eclipse Che 的用户机器上创建并启动 docker 容器。攻击者控制下的众多参数允许进行精确的控制。一些开发人员将 Che 以独立模式运行，作为管理其本地 docker 容器的一种便捷方式。
之所以可能，是因为默认情况下 Che 启用了 CORS。对于了解其含义的人来说，这些问题相当明显，但本质上，Che 会响应来自任何来源的请求。尽管浏览器尽力使 CORS 攻击变得困难，但当服务器允许 CORS 时，从远程站点向本地运行的 Che 服务成功发出 POST 请求是可能的。
本质上，这意味着当以独立模式运行 Che 的计算机访问他们的网站时，任何未经身份验证的 API 方法都可以被调用。这包括创建和运行新的 Docker/OpenShift 容器。
本自述文件包含一个简单的 POC，但查看发布到本地 Che 服务的 JSON 会发现许多相当有趣的参数可供控制，包括使用哪个镜像、启动时运行哪些命令、在容器中启动哪些服务器以及其他相当有趣的特性。
要利用此漏洞，您必须针对在计算机上运行 Eclipse Che 的人。您必须让目标访问您控制的、通过 HTTP 提供的页面。从那里，XMLHttpRequest 会完成它的工作，您就可以大展拳脚了。要充分理解如何利用此漏洞，您应该查看 Che 的源代码以了解 API，或者直接摆弄一下我在这个仓库中放置的 POC。本质上，您想要创建一个容器，或者在新启动的容器中创建一个命令，从而获得您想要的那种立足点。您可以设置自己选择的服务器，或者干脆让命令在启动时运行，下载您的载荷，然后从那里开始操作。这种攻击既适用于机会主义攻击，也适用于针对性攻击。
有关更详细的讨论，请查看此处跟踪的漏洞。其中大部分内容只是在重复这篇文章。
要成功执行此攻击，页面必须由 HTTP（而非 HTTPS）服务器提供。 这是必要的，因为本地 Che 服务器通过 HTTP 运行，而主流浏览器不喜欢混用 HTTP 和 HTTPS 内容。
为解决此问题，Che 团队默认禁用了 CORS。这至少应该使此类攻击在未来变得更加困难。如果您在本地运行 Che 来管理 docker 镜像，请考虑升级。
