Databricks于2019年2月12日意识到一个新的关键runc漏洞（CVE-2019-5736），该漏洞允许恶意容器用户获得对主机操作系统的根访问权限。此漏洞影响许多容器运行时，包括Docker和LXC。Databricks安全团队已经评估了该漏洞，并确认，由于Databricks平台架构，攻击者不存在利用该漏洞访问容器所在主机虚拟机的外部向量。此外，我们的体系结构通过向每个客户提供位于客户云服务帐户内的独立主机虚拟机来隔离每个客户，因此即使底层容器受到损害，此漏洞利用也不会允许任何跨客户访问。该CVE包括两个攻击向量：使用攻击者控制的映像创建新容器。Databricks只启动Databricks工程团队构建的容器，因此恶意的外部用户无法启动自己的映像。附加到攻击者以前具有写访问权限的现有容器。只有Databricks服务可以附加到现有容器。用户通过RPC访问容器，无法附加到现有容器。尽管我们相信这个漏洞在我们的环境中不太可能被实际利用，但Databricks engineering将推出一个热修复程序，该补丁程序将尽快部署。这个漏洞是如何详细工作的？利用此漏洞会尝试破坏容器运行时二进制文件以获得对主机的根访问权限。容器运行时是一个二进制程序，运行在主机系统上，并在容器内协调进程的执行。它被设计为确保容器的进程在它们自己的独立名称空间中运行，并且具有减少的特权。在docker上，默认的容器运行时是runC binary，而在LXC上则是其他LXC-*实用程序。以lxc attach为例，恶意用户可以通过以下步骤发起攻击：用指向lxc附加二进制文件本身的自定义内容替换容器中的目标二进制文件。例如，可以将容器的/bin/bash替换为以下内容：#!/proc/self/exe程序这样，/bin/bash（容器路径）就变成了一个可执行脚本，使用/proc/self/exe来解释其恶意内容。注意，/proc/self/exe是内核为每个进程创建的符号链接，它指向为该进程执行的二进制文件。欺骗容器运行时从主机系统执行目标二进制文件。因此，当在容器内执行/bin/bash时，将执行/proc/self/exe的目标-它将指向主机上的容器运行时二进制文件。在本例中，当攻击者使用lxc attach在容器内运行命令时，lxc attach使用execve（）syscall调用容器的/bin/bash，后者又运行/proc/self/exe，即lxc attach本身来解释注入的恶意负载。继续写入/proc/self/exe的目标，以便覆盖主机上的lxc attach二进制文件。但是，一般来说，这不会成功，因为内核不允许在执行lxc attach时覆盖它。为了克服这个问题，攻击者可以使用O_PATH标志打开/proc/self/exe，以获取文件描述符，然后通过/proc/self/fd/以O帴WRONLY的形式重新打开二进制文件，并尝试从新分叉的子进程中以繁忙的循环方式写入该文件。最终，当父lxc attach进程退出时，它将成功。在此之后，主机上的lxc-attach二进制文件被破坏，可用于攻击其他容器或主机本身。可以在目标1中从目标注入恶意负载重写逻辑。因此，有三个主要条件可以使攻击生效：攻击者必须拥有或获得对图像内容的控制权，才能替换容器中的目标二进制文件。如果攻击者控制容器映像或以前具有对容器的写访问权限，这是可以实现的。攻击者必须能够通过某些外部通道调用主机系统上的容器运行时。如果主机系统公开一个API层（例如kubelet API服务器），允许用户间接调用容器运行时二进制文件，则会出现这种情况。例如，如果有一个API允许远程用户使用自定义映像启动容器，或者使用lxc attach或docker exec附加到正在运行的容器攻击者必须具有从容器重写主机容器运行时二进制文件的内容的权限。如果容器以特权用户身份在主机系统上运行，则这是可能的，但如果容器以非特权用户身份运行，则不可能。Databricks只公开了一个API来启动带有我们工程团队发布的可信Databricks运行时映像的容器，这些容器在附加或创建之前不受用户的修改。由于创建后修改的映像不能用于利用此漏洞，因此受信任的容器状态使Databricks标准体系结构不受影响。此外，Databricks工作区用户通过运行在容器内的RPC服务器访问容器，因此不能使用低级容器运行时二进制文件连接到现有容器。 免费试用Databricks。今天就开始吧