Docker镜像并不安全

问题导读


1.镜像从HTTPS服务器上下载下来，然后通过Docker daemon的流处理管道，这个管道为什么是不安全的？
2.Docker镜像不安全该如何解决？








【编者的话】作者深入研究了Docker镜像的下载流程，并逐步分析了Docker镜像下载过程中可能出现的安全问题。关注Docker安全以及做Docker镜像存储的同学必看。另外，作者还总结了应该采取哪些措施来改善Docker镜像的安全性。

最近在使用Docker下载一个“官方”容器镜像时我看到这么一行提示：

ubuntu:14.04: The image you are pulling has been verified

我当时以为这和Docker极力推荐的镜像签名系统有关，所以并未深究。后来，在研究Docker镜像安全相关的加密系统时，我开始进一步探索Docker的镜像安全。而我发现所有与镜像安全相关的逻辑完全是系统性的错误。

按照Docker的说法，下载的镜像完全是基于签名的manifest的存在而做出的，并且Docker并没有从manifest中校验镜像的校验和（checksum）。攻击者可以伪造提供一个具有签名证明的镜像，这个问题很容易被攻击者利用。

镜像从HTTPS服务器上下载下来，然后通过Docker daemon的一个不安全的流处理管道：

[解压缩] -> [tarsum] -> [解包]
复制代码

这个管道很高效，但毫无安全可言。在未验证签名之前，管道不应该处理不受信任的输入。然而，在验证检验和之前，Docker进行了三次镜像的处理。

尽管Docker做了声明，但它从未实际检查过镜像校验。下面是Docker中唯一一处与验证镜像校验和有关的代码，但是即便在镜像中提供不匹配的校验和，我也无法触发这个警告。

if img.Checksum != "" && img.Checksum != checksum {
log.Warnf("image layer checksum mismatch: computed %q,
         expected %q", checksum, img.Checksum)
}
复制代码

不安全的处理管道解压缩Docker支持三种压缩算法：gzip、bzip2和xz。前两者使用Go的标准库实现，这是内存安全的，所以我能想到的漏洞类型是拒绝服务攻击，如宕机、CPU和内存过度使用。

第三个压缩算法xz更有趣。因为没有原生的Go实现，Docker运行xz程序来解压缩。

xz程序来自XZ Utils项目，它从接近2万行C代码中构建而来。C不是一个内存安全的语言。这意味着一个C程序的恶意输入，此处为XZ Utils正在解包的Docker镜像，有执行任意的代码的可能。

如果Docker以root运行xz，那会更糟糕，这意味着如果xz存在一个漏洞，执行docker pull将严重危及你的整个系统。
Tarsumtarsum的使用出于好意，但完全错误。为了取得一个任意编码的tar文件的确定性校验和，Docker对tar进行解码然后以确定性顺序对特定部分进行哈希，排除了其他部分。

因为这个处理过程是为了生成校验和，它正在解码的不受信任的数据可被设计成利用tarsum代码的漏洞。这里可能的漏洞是拒绝服务攻击以及逻辑缺陷，这将引起文件在不改变校验和的情况下被注入、跳过、使用不同方式处理、修改、添加等。
解包解包分为tar解码和将文件到保存到硬盘中两个步骤，在编写本文的时候已经有解包阶段的三个其他漏洞被报告出来，所以这也是非常危险的。

不应该存在未被检验的数据被解包到硬盘中的情况。
libtrustlibtrust是一个提供认证和权限控制的Docker包。但是官方没有提供任何的规范，但它看起来像是实现了Javascript对象签名与加密规范的一部分，以及其他不明算法。

所以在下载一个manifest签名的以及使用libtrust验证的镜像时，会有如下不准确的提示：

ubuntu:14.04: The image you are pulling has been verified
复制代码

目前只有Docker公司公布的“官方”镜像manifest使用这个系统签名，但从我参加的最近一次Docker管理咨询委员会会议的讨论看来，Docker公司计划在未来更广泛的部署它。目标应该是集中管理，由Docker公司控制一个发证机构用于镜像和/或客户证明签名。

我曾在Docker代码中查找签名密钥，但没找到。看来密钥并没有嵌入到程序中。实际上，Docker后台会在每次镜像下载时通过HTTPS从CDN获取密钥。这是一个非常糟糕的方式，因为有很多种攻击可以导致受信任的密钥被替换成恶意的。这种攻击包括但不限于：CDN供应商威胁、CDN供应密钥源威胁以及客户端下载密钥时的中间人攻击。
补救在完成此项研究之前，我已经报告了我发现的tarsum系统的几个问题，但至今没有一个被修复。

我觉得必须采取一些措施来改善Docker镜像下载系统的安全性：
弃用tarsum并实际验证镜像摘要为安全起见，不应该使用tarsum。取而代之的是在进行任何处理前，将镜像完全下载并对其加密签名进行验证。
增加权限隔离涉及解压缩或解包的镜像处理步骤必须运行于具有最低限度的必要的权限的隔离的程序（容器？）中。不应该存在像xz这样的解压缩工具必须以root运行的情况。
更换libtrust用The Update Framework替换libtrust，前者是明确设计用于解决软件程序签名的实际问题的。它的威胁模型非常全面，并且解决了很多libtrust没有考虑到的事情。它拥有一个完整的规范，以及一个Python的参考实现，我已经开始Go的实现并且欢迎任何人加入。

作为添加TUF到Docker的一部分，一个映射根密钥到registry URL的本地密钥库将被加入，以便用户可以使用不受Docker公司管理的自有签名密钥。

我想指出的是，一般情况下使用非Docker公司托管的registry用户体验非常差。在没有任何技术原因的情况下，Docker公司似乎乐于将第三方registry降低为二等地位。这对一般的生态系统和最终用户的安全来说都是个问题。综合而言，针对第三方registry的分散的安全模型是必要和可取的。我非常期待Docker公司在重新设计他们的安全模型和镜像验证系统时考虑这一点。

结论Docker用户应该清楚负责下载镜像的代码是极其不安全的。用户只能下载那些来源没有问题的镜像。目前，这不包括托管于Docker公司的“可信的”的镜像，包括官方的Ubuntu和其他基础镜像。

最好的办法是在本地阻止index.docker.io，并在镜像导入到Docker之前手动使用docker load下载并检验镜像。