容器镜像是容器环境的重要组成部分，作为整个容器生命周期的源头，其安全性应引起用户的广泛关注。本文针对Docker镜像，对其进行深入的脆弱性分析。
1.容器镜像概述
镜像是容器运行的基础，容器服务引擎可以使用不同的镜像启动相应的容器实例。在容器实例出现异常后，能迅速通过删除实例、启动新的容器实例来恢复服务，这些灵活、敏捷的操作，均需要以容器镜像作为支撑技术。
与虚拟机所用的系统镜像不同，容器镜像不仅没有Linux系统内核，同时在格式上也有很大的区别。虚拟机镜像是将一个完整的操作系统封装成一个镜像文件，而容器镜像不是一个文件，是分层存储的文件系统。
图1 容器镜像结构
上图是Docker镜像分层存储的示意图，从图中可以看出，每个镜像都是由一系列的“镜像层”组成。当需要修改镜像内的某个文件时，只会对最上方的读写层进行改动，不会覆盖下层已有文件系统的内容。当提交这个修改生成新的镜像时，保存的内容仅为最上层可读写文件系统中被更新过的文件，这样就实现了在不同的容器镜像间共享镜像层的效果。
容器镜像通常会通过镜像仓库（Registry）进行存储和管理。根据Registry服务的提供者、镜像存储位置、访问控制等因素，可以将其分为公共仓库和私有仓库。
因此，对于镜像的来源，无非就是这两种渠道：或者是通过公共的镜像仓库获取，比如Docker官方的Docker Hub、或者是国内的网易163、中科大（USTC）、daocloud、阿里云等；或者是用户自己维护一个私有仓库，比如采用Harbor，团队所有成员将相关的镜像上传至私有仓库，供其他成员使用。
对于开发者来说，公共仓库获取镜像的便利性，使其成为很多开发者获取镜像的重要途径。从Docker Hub显示的数字来看，Nginx、Redis、Tomcat等常用应用的镜像下载量，均在千万以上的数量级。中国信通院2018年3月份发布的《开源治理白皮书》[1]中提到，截至2014年底，容器镜像下载量高达1亿，到2017年初，这一数量超过80亿。
2.开源软件风险分析
提及容器镜像，不得不提的就是开源软件，根据Gartner的调查显示，99%的组织在其IT系统中使用了开源软件，同时开源软件在服务器操作系统、云计算、Web等领域都有比较广泛的应用。而从Docker Hub中可以看到，几乎所有常用的开源软件，均可以在公共仓库中找到相应的Docker镜像，比如TensorFlow、Kafka、Pytorch、Zepplin等。
图2 Docker Hub中的TensorFlow镜像检索
回到安全的角度来看，容器镜像作为开源软件使用的一个载体，要解决容器镜像的安全问题，那么开源软件所面临的安全风险，是必然要考虑的一个问题。
比如：（1）确认已经解决已知的安全漏洞（包括自研代码和引用的第三方代码），如软件注入漏洞等。如仍然存在显著漏洞，应予以修补，避免开放被使用后影响公众安全；（2）确认开源代码和文档中是否存在泄漏用户隐私和商业秘密的情况；（3）确认是否泄漏了秘钥、账号、密码、测试IP地址、端口、测试用例等敏感信息；（4）确认是否包含挖矿程序、后门程序、病毒、木马等恶意代码。
开源软件存在的安全问题中，安全漏洞是一个重要的问题，根据NVD数据统计，截至2017年2月，全球开源软件相关的已知安全漏洞已超过28000个。截至2017年2月，美国国土安全部累计检测各种开源软件7000多个，发现大量安全缺陷。系统信息泄露、密码管理、资源注入、跨站请求伪造、跨站脚本、HTTP消息头注入、SQL注入、跨界访问、命令注入、内存泄露等是开源软件主要的安全风险。
图3 开源软件项目缺陷总数
开源软件带来的安全风险[2]，近年来频繁的被揭露出来。例如，2017年，Equifax指责开源Apache Struts被用于网络攻击，导致了1.43亿条记录的泄露。同一年，Black Duck Software的研究人员通过对企业中1,000种常用应用程序的审计发现，96％的企业使用开源软件，60％以上包含由于这些组件造成的安全漏洞。一些被发现的漏洞已存在超过了四年之久。
2017年11月，Uber发布声明，承认2016年曾遭黑客攻击并导致数据大规模泄露。根据这份声明，两名黑客通过第三方云服务对Uber实施了攻击，获取了5700万名用户数据，包括司机的姓名和驾照号码，用户的姓名、邮箱和手机号。调查发现，Uber数据泄露的原因竟然是工程师将解锁数据库的安全密钥存储在GitHub的一个可以公开访问的页面。
3.镜像脆弱性分析
对于容器镜像的安全性来说，开源软件的安全风险仅仅是容器镜像脆弱性的一个子集。下面本文将详细介绍容器镜像所面临的脆弱性问题。
3.1 镜像来源
3.1.1 公共镜像的安全威胁
从用户角度来看，容器镜像在获取途径上，我们将其分为“从公共仓库获取”以及“从私有仓库获取”两种，那么对于从公共仓库获取的镜像，最重要的两个脆弱性问题：一方面是镜像中软件的安全漏洞问题；另一方面是镜像内的挖矿程序、后门程序、病毒、木马等恶意程序。
容器的镜像，从某种意义上来看，其实就是系统软件或者是应用软件的一种交付形式，那么从安全的角度来看，软件漏洞将是给软件带来安全风险的最直接也是最重要因素，因此讨论容器镜像的安全，首要考虑的因素就是镜像中软件漏洞的管理。
有关研究报告[3]显示，Docker Hub中超过30%的官方镜像包含高危漏洞，接近70%的镜像有着高危或中危漏洞。
笔者从Docker Hub中选择评价和下载量较高的10个镜像，对其最新版本（latest）采用Clair工具进行了扫描分析。从结果可以看出，如此高频率使用的镜像，绝大多数均存在高危漏洞，有的镜像高危漏洞数量甚至达到数十个之多。
图4 Docker Hub中部分镜像漏洞情况统计
当然，笔者这里对于公共仓库中镜像的漏洞统计，只是采用开源的工具，直接对镜像的漏洞进行了一个简单的扫描分析。对于这样的结果，并不代表公共仓库的镜像真的就危险到不可以使用。当然也不能排除扫描工具在漏洞处理上存在的一些问题。
由于公共仓库是对所有用户开放的，任何用户都可以从仓库中获取现有的容器镜像，当然也可以将自己制作的镜像上传至公共仓库，供其它用户使用。如果有黑客在制作镜像时植入木马、后门等恶意软件，并将恶意镜像上传至Docker Hub等公共仓库，那么用户的容器环境从一开始就已经不安全了，后续更没有什么安全可言。
比如Docker对镜像不安全的处理管道，Docker支持三种压缩算法，分别是gzip、bzip2、xz。gzip和bzip2使用Go的标准库，所以相对安全；xz由于没有使用原生的Go去实现，又由于其使用由C编写的XZ Utils开源项目，所以存在C程序恶意写入的可能，一旦被写入会导致执行任意代码漏洞，而只要有一个漏洞，执行docker pull拉取镜像时就有可能导致整个系统沦陷。
2018年6月，就有安全厂商发现17个受到感染的Docker容器镜像[4]，镜像中包含了可用于挖掘加密货币的程序，更危险的是，这些镜像的下载次数已经高达500万次。
对于特定某文件，一般可以使用杀毒软件进行扫描以确定该文件是否安全，但是目前的杀毒软件并没有能够很好支持镜像的扫描。用户想确认下载的镜像是否安全，只能仔细检查下载的源是否有后门（比如运行镜像，然后在里面安装杀毒软件扫描），并且确认请求指向官方源。
3.1.2 私有镜像的安全威胁
对于私有仓库中的镜像，通常是用户自己制作上传生成的，那么其脆弱性一方面包括软件代码本身的脆弱性，另一方就是配置的风险。
软件代码的脆弱性，不仅需要在开发过程中尽可能遵循SDL（安全开发生命周期），在开发完成后，同样需要进行代码审计、渗透测试等安全检查，保证应用的镜像在生成之前，已经解决所有已知的代码漏洞。
在制作镜像的过程中，镜像内是否包含了账号密码等信息、是否包含了秘钥文件信息、是否暴露其它敏感信息、是否运行了禁止运行的命令等问题，在镜像入库之前，也是要重点进行检测的。
另外，用户在使用容器的时候，很自然地会和虚拟机进行类比，比如怎么进入容器内进行调试、sshd怎么配置等。要正确的使用容器，一定要有容器化的思维，正确的认识容器。特别是在微服务体系中，容器的本质就是一个或少数进程以及运行进程所需要的各种依赖，即运行时环境的最小集。因此，在镜像制作过程，一定要尽可能的只运行必要的服务，只暴露出必要的端口。
如果在容器中运行了SSH、TELNET等服务，不仅不会增加该微服务的功能，反而会带来一系列的安全威胁以及增加安全运维的复杂度。比如SSH服务的访问策略和安全合规性管理、各种容器的秘钥以及密码管理、SSH服务安全升级等。
3.2 镜像传输
容器镜像在下载和上传时需保证完整性和秘密性，以下建议有助于抵御如中间人攻击等威胁：
（1）数字签名。上传者主动给要上传的镜像签名，下载者获取镜像时先验证签名再使用，防止其被恶意篡改。
（2）用户访问控制。敏感系统和部署工具（注册中心、编排工具等）应该具备有效地限制和监控用户访问权限的机制。
（3）尽可能使用支持HTTPS的镜像仓库。为避免引入可疑镜像，用户谨慎使用–insecure-registry选项连接来源不可靠的HTTP镜像仓库。
4. 镜像脆弱性评估示例
当前，针对容器镜像的脆弱性问题，一些容器安全的厂商以及开源项目，均提供了相应的检测能力，下表[5]中对几个常见的扫描工具从功能、开源等几个方面进行了对比分析。
对于镜像的脆弱性检测，其中涉及到几个核心的环节。检测工具需要获取当前的所有漏洞信息，通常会从主流的漏洞平台获取，比如NVD。
获取待检测镜像，并针对镜像的每一层进行解析，获取到镜像中所有的软件包以及对应的版本信息。
这样，根据软件包的版本信息以及漏洞库信息，就可以对容器镜像内的应用软件进行CVE的检测了。
在对容器镜像进行解析的时候，不仅可以获取到相应软件包的版本信息，同时还能精确的分析到镜像内的所有文件。这样假如存在“/etc/ssh/ssh_host_dsa_key”、“/home/user/.ssh/id_rsa”这样的敏感秘钥信息，可以对其进行告警。
下面，我们使用Clair（latest）针对Ubuntu 14.04进行扫描测试，并尝试进行漏洞修复。
首先对Ubuntu:14.04镜像进行扫描（clairctl analyze registry.securityapp.store/library/ubuntu:14.04 –log-level Debug），扫描过程如下图所示。
经过逐层的分析，扫描结果如下图。
使用clairctl将所报漏洞以报表（html格式）的形式输出（clairctl report -l registry.securityapp.store/library/ubuntu:14.04 –log-level debug），过程如下图所示。
使用docker cp（docker cp fda246b5625c:/reports/html/analysis-registry.securityapp.store-library-ubuntu-14.04.html /tmp/）将html文件输出至本地后，用浏览器打开报表。
由上图可以看出，报告中已经将高、中、低以及可忽略的漏洞友好的分类显示出来，其中高危漏洞1个，中危漏洞50个，低危漏洞78个，可忽略漏洞24个。此处我们将高危漏洞找出，具体漏洞如下图所示。
点击漏洞链接可知目前官方的Ubuntu 14.04 LTS（Trusty Tahr）已发布了release版本2.19-0ubuntu6.14，修复了此漏洞。
接下来，我们将含有漏洞的镜像运行为容器（docker run -dt –name ubuntu-test-clair registry.securityapp.store/library/ubuntu:14.04），并且进入容器内部（docker exec -it 9bcf21a481d0 /bin/bash），过滤查看容器内含有漏洞的软件包信息，看到漏洞版本号为2.19-0ubuntu6.13。
然后对这两个软件包进行升级，待升级成功后，再次查看包的版本信息，已升级为最新版本2.19-0ubuntu6.14，如下图所示。
将这个容器打包为一个新的镜像（docker commit 9bcf21a481d0 ubuntu-fixed-clair），并上传是镜像仓库（docker tag ubuntu-fixed-clair:latest registry.securityapp.store/test/ubuntu-fixed-clair:latest，docker push registry.securityapp.store/test/ubuntu-fixed-clair:latest）。
通过Clair扫描这个漏洞修复后的镜像（clairctl analyze -l registry.securityapp.store/test/ubuntu-fixed-clair:latest –log-level debug），扫描结果如下图所示。
从扫描结果可以看出，之前含有高危漏洞的Ubuntu 14.04镜像经过手动修复漏洞并重新打包为新的镜像后，之前的高危漏洞已不存在。
参考文献
[1] 开源治理白皮书（2018）, http://www.caict.ac.cn/kxyj/qwfb/ztbg/201804/P020180323313495961952.pdf
[2] 2018 Open Source Security and Risk Analysis, https://www.synopsys.com/content/dam/synopsys/sig-assets/reports/2018-ossra.pdf
[3] Over 30% of Official Images in Docker Hub Contain High Priority Security Vulnerabilities, https://www.banyanops.com/blog/analyzing-docker-hub/
[4] Tainted, crypto-mining containers pulled from Docker Hub, https://techcrunch.com/2018/06/15/tainted-crypto-mining-containers-pulled-from-docker-hub/
[5] https://www.meetup.com/Cloud-Native-days-china/events/251975991/
报告下载
点击此链接，下载《2018绿盟科技容器安全技术报告》完整版。
https://blog.nsfocus.net/global-threat-analysis-container-safety
添加好友，备注“进群”，加入容器安全技术交流群，通过后会拉您入群。