Docker 映像不安全

最近用Docker在下载一个官方镜像容器时我看到了这一行：

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

我以为这引用了Docker 大力推广的镜像签名系统，当时并没有深究。不久之后，在研究Docker用以加密镜像的加密摘要系统时，有了继续研究的机会。我发现镜像安全相关的所有逻辑完全系统性的失效。

Docker 的报告称一个下载的镜像仅仅以一个签过名的清单为验证基础, 并且Docker从不校验清单上的镜像的总和校验码。攻击者可以提供任意带有签名清单的镜像。这为一系列严重的漏洞埋下了隐患。

镜像通过一个Docker守护进程里无安全的流处理管道从一个HTTPS服务器上下载

[decompress] -> [tarsum] -> [unpack]

这个管道高效但不安全。非置信的输入不应在校验签名之前处理。不幸的是Docker在总和校验码验证之前要处理镜像三次。

不管 Docker的声明如何，镜像总和校验码从来没有实际校验过。这只是Docker校验镜像总和校验码相关的代码的section⁰ ，在呈现一个有错误总和校验码的镜像时我甚至无法打开警告触发器。

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执行thexzbinary来解压缩。

Thexzbinary 来自于XZ Utils项目，构建自大约20000行的C代码。C并不是一个内存安全的语言。这意味着存在向C程序恶意输入的可能，这样的话Docker 镜像XZ Utils就被开箱了，可能会执行任意代码。

通过以管理员权限运行xz，Docker加剧了这个情况的发生。意味着只要在xz中存在一个漏洞，一个docker pull的调用就将导致整个系统的沦陷。

Tarsum

tarsum的使用原本是善意的但却完全错了。为得到一个编码任意的tar文件的真实校验和，Docker对tar解压然后取特定部分的哈希，以一个特定序列却不包含剩余部分。

由于这个处理是为了生成校验和，它解压了设计用来生成tarsum码2非可信数据。这里会有DOS和逻辑缺陷攻击的风险，可能导致文件被注入，跳过，差异化地处理，修改，添加等等。而校验和不会变化。

解压

解压包括解压tar并将文件放置到磁盘上。这也是非常危险，在写本文时已有三个其他的解压阶段的漏洞报告2 。

当文件还没被校验就解压到磁盘上时还没有解决措施。

libtrust

libtrust是Docker的一个包，宣称提供“通过一个分布式的信任图来控制认证和访问。”但不幸的是不存在详细说明书，但它看起来像是实现了Javascript Object Signing and Encryption说明的一部分和其他未指明的算法。

下载一个使用libtrust签名和认证清单的镜像，会触发这个不安全的信息（仅仅检查了清单，而不是真实的镜像内容）：

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

目前只有Docker，Inc发布的“官方”镜像使用这个系统签名，但从我最近参加的Docker Governance Advisory Board会议看，我的理解是Docker， Inc打算将来更广泛的部署这个系统。计划的目标是由Docker，Inc集中控制证书的认证，然后在镜像和/或客户端的证书上签名。

我在Docker的代码里找签名钥匙，但没能找到。结果证明这个钥匙并不像期望那样嵌入到了二进制程序中。相反，Docker后台程序在各个镜像下载前，使用HTTPS从CDN上获取。这个方法很糟糕，因为很多攻击可以导致信任的钥匙被恶意的替换。这些攻击包括但不限于：CDN主的妥协，CDN原有托管钥匙的妥协，以及客户端的中间人攻击来下载钥匙。

修补措施

在我完成本次研究前，我报告了我发现的tarsum系统的一些问题，但目前为止我还没发现它们被修复。我认为以下措施有助于提高Docker镜像下载系统的安全：

丢弃tarsum，真实验证镜像摘要

Tarsum不应该用于安全。相反，镜像必须被完整下载，它们的私密签名要在进一步处理发生前进行验证。

添加权限隔离

镜像的处理步骤，包括解压或展开，应该在隔离的仅有最少必要操作权限的进程（容器？）中运行。没有像xz这样的解压工具在root下运行的场景。

替换libtrust

libtrust应该被The Update Framework替代，它被设计出来明显就是为了解决软件二进制签名的问题。威胁模型非常好理解，也强调了许多在libtrust里面没有考虑到的事。它有完整的说明书，也有一个Python的参考实现，我已经开始用Go实现，欢迎对其贡献。

作为添加TUF到Docker中的一部分，应该添加一个本地key仓库，用来将root钥匙映射到注册的URL上，这样用户就可以有自己的签名钥匙，而不是被Docker，Inc管理。

我想强调的是，使用非Docker，Inc托管的登记一般来说是非常差的用户体验。Docker，Inc看起来把第三方登记降为第二等级的状态很满意，而并没有这样做的技术原因。这对于常见的生态系统和终端用户的安全都是一个问题。一个广泛的、去中心化的安全模型对与第三方登记来说，既是必要的也是值得的。我建议Docker，Inc在重新设计他们的安全模型和镜像认证系统时考虑下这个问题。

结论

Docker 用户要意识到下载镜像是非常不安全的。要只下载那些源没有问题的镜像。当前，这个问题没有影响到docker提供的信任的镜像，包括官方的Ubuntu镜像和其他的基本镜像。

最好的选择是本地屏蔽掉‘index.docker.io’，并且在使用‘docker load’导入到docker之前，先手动下载、验证一下镜像文件。Red Hat的安全论坛上有很多好的相关的帖子（https://securityblog.RedHat.com/2014/12/18/before-you-initiate-a-docker-pull/）。

感谢Lewis Marshall 指出了tarsums一直没有验证的问题。

Docker 的详细介绍：请点这里
Docker 的下载地址：请点这里