mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-28 23:20:10 +08:00
Merge remote-tracking branch 'upstream/master' into newbranch
This commit is contained in:
Ping
commit
516c0fcd53
@ -1,4 +1,4 @@
|
||||
伴随Apple Watch的揭幕，下一个智能手表会是Ubuntu吗？
|
||||
Apple Watch之后，下一个智能手表会是Ubuntu吗？
|
||||
===
|
||||
|
||||
**苹果借助‘Apple Watch’的发布，证实了其进军穿戴式电子设备市场的长期传言**
|
||||
@ -1,10 +1,10 @@
|
||||
Linux有问必答-- 如何在Linux上安装内核头文件
|
||||
Linux有问必答：如何在Linux上安装内核头文件
|
||||
================================================================================
|
||||
> **提问**:我在安装一个设备驱动前先要安装内核头文件。怎样安装合适的内核头文件？
|
||||
|
||||
当你在编译一个设备驱动模块时，你需要在系统中安装内核头文件。内核头文件同样在你编译与内核直接链接的用户空间程序时需要。当你在这些情况下安装内核头文件时，你必须确保内核头文件精确地与你当前内核版本匹配（比如：3.13.0-24-generic）。
|
||||
|
||||
如果你的内核发行版自带的内核版本，或者使用默认的包管理器的基础仓库升级的（比如：apt-ger、aptitude或者yum），你也可以使用包管理器来安装内核头文件。另一方面，如果下载的是[kernel源码][1]并且手动编译的，你可以使用[make命令][2]来安装匹配的内核头文件。
|
||||
如果你的内核是发行版自带的内核版本，或者使用默认的包管理器的基础仓库升级的（比如：apt-ger、aptitude或者yum），你也可以使用包管理器来安装内核头文件。另一方面，如果下载的是[kernel源码][1]并且手动编译的，你可以使用[make命令][2]来安装匹配的内核头文件。
|
||||
|
||||
现在我们假设你的内核是发行版自带的，让我们看下该如何安装匹配的头文件。
|
||||
|
||||
@ -41,7 +41,7 @@ Debian、Ubuntu、Linux Mint默认头文件在**/usr/src**下。
|
||||
|
||||
假设你没有手动编译内核，你可以使用yum命令来安装匹配的内核头文件。
|
||||
|
||||
首先，用下面的命令检查系统是否已经按炸ung了头文件。如果下面的命令没有任何输出，这就意味着还没有头文件。
|
||||
首先，用下面的命令检查系统是否已经安装了头文件。如果下面的命令没有任何输出，这就意味着还没有头文件。
|
||||
|
||||
$ rpm -qa | grep kernel-headers-$(uname -r)
|
||||
|
||||
@ -66,7 +66,7 @@ Fedora、CentOS 或者 RHEL上默认内核头文件的位置是**/usr/include/li
|
||||
via: http://ask.xmodulo.com/install-kernel-headers-linux.html
|
||||
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
@ -1,134 +0,0 @@
|
||||
翻译中 by小眼儿
|
||||
|
||||
Docker Image Insecurity
|
||||
================================================================================
|
||||
Recently while downloading an “official” container image with Docker I saw this line:
|
||||
|
||||
ubuntu:14.04: The image you are pulling has been verified
|
||||
|
||||
I assumed this referenced Docker’s [heavily promoted][1] image signing system and didn’t investigate further at the time. Later, while researching the cryptographic digest system that Docker tries to secure images with, I had the opportunity to explore further. What I found was a total systemic failure of all logic related to image security.
|
||||
|
||||
Docker’s report that a downloaded image is “verified” is based solely on the presence of a signed manifest, and Docker never verifies the image checksum from the manifest. An attacker could provide any image alongside a signed manifest. This opens the door to a number of serious vulnerabilities.
|
||||
|
||||
Images are downloaded from an HTTPS server and go through an insecure streaming processing pipeline in the Docker daemon:
|
||||
|
||||
[decompress] -> [tarsum] -> [unpack]
|
||||
|
||||
This pipeline is performant but completely insecure. Untrusted input should not be processed before verifying its signature. Unfortunately Docker processes images three times before checksum verification is supposed to occur.
|
||||
|
||||
However, despite [Docker’s claims][2], image checksums are never actually checked. This is the only section[0][3] of Docker’s code related to verifying image checksums, and I was unable to trigger the warning even when presenting images with mismatched checksums.
|
||||
|
||||
if img.Checksum != "" && img.Checksum != checksum {
|
||||
log.Warnf("image layer checksum mismatch: computed %q,
|
||||
expected %q", checksum, img.Checksum)
|
||||
}
|
||||
|
||||
### Insecure processing pipeline ###
|
||||
|
||||
**Decompress**
|
||||
|
||||
Docker supports three compression algorithms: gzip, bzip2, and xz. The first two use the Go standard library implementations, which are [memory-safe][4], so the exploit types I’d expect to see here are denial of service attacks like crashes and excessive CPU and memory usage.
|
||||
|
||||
The third compression algorithm, xz, is more interesting. Since there is no native Go implementation, Docker [execs][5] the `xz` binary to do the decompression.
|
||||
|
||||
The xz binary comes from the [XZ Utils][6] project, and is built from approximately[1][7] twenty thousand lines of C code. C is not a memory-safe language. This means malicious input to a C program, in this case the Docker image XZ Utils is unpacking, could potentially execute arbitrary code.
|
||||
|
||||
Docker exacerbates this situation by *running* `xz` as root. This means that if there is a single vulnerability in `xz`, a call to `docker pull` could result in the complete compromise of your entire system.
|
||||
|
||||
**Tarsum**
|
||||
|
||||
The use of tarsum is well-meaning but completely flawed. In order to get a deterministic checksum of the contents of an arbitrarily encoded tar file, Docker decodes the tar and then hashes specific portions, while excluding others, in a [deterministic order][8].
|
||||
|
||||
Since this processing is done in order to generate the checksum, it is decoding untrusted data which could be designed to exploit the tarsum code[2][9]. Potential exploits here are denial of service as well as logic flaws that could cause files to be injected, skipped, processed differently, modified, appended to, etc. without the checksum changing.
|
||||
|
||||
**Unpacking**
|
||||
|
||||
Unpacking consists of decoding the tar and placing files on the disk. This is extraordinarily dangerous as there have been three other vulnerabilities reported[3][10] in the unpack stage at the time of writing.
|
||||
|
||||
There is no situation where data that has not been verified should be unpacked onto disk.
|
||||
|
||||
### libtrust ###
|
||||
|
||||
[libtrust][11] is a Docker package that claims to provide “authorization and access control through a distributed trust graph.” Unfortunately no specification appears to exist, however it looks like it implements some parts of the [Javascript Object Signing and Encryption][12] specifications along with other unspecified algorithms.
|
||||
|
||||
Downloading an image with a manifest signed and verified using libtrust is what triggers this inaccurate message (only the manifest is checked, not the actual image contents):
|
||||
|
||||
ubuntu:14.04: The image you are pulling has been verified
|
||||
|
||||
Currently only “official” image manifests published by Docker, Inc are signed using this system, but from discussions I participated in at the last Docker Governance Advisory Board meeting[4][13], my understanding is that Docker, Inc is planning on deploying this more widely in the future. The intended goal is centralization with Docker, Inc controlling a Certificate Authority that then signs images and/or client certificates.
|
||||
|
||||
I looked for the signing key in Docker’s code but was unable to find it. As it turns out the key is not embedded in the binary as one would expect. Instead the Docker daemon fetches it [over HTTPS from a CDN][14] before each image download. This is a terrible approach as a variety of attacks could lead to trusted keys being replaced with malicious ones. These attacks include but are not limited to: compromise of the CDN vendor, compromise of the CDN origin serving the key, and man in the middle attacks on clients downloading the keys.
|
||||
|
||||
### Remediation ###
|
||||
|
||||
I [reported][15] some of the issues I found with the tarsum system before I finished this research, but so far nothing I have reported has been fixed.
|
||||
|
||||
Some steps I believe should be taken to improve the security of the Docker image download system:
|
||||
Drop tarsum and actually verify image digests
|
||||
|
||||
Tarsum should not be used for security. Instead, images must be fully downloaded and their cryptographic signatures verified before any processing takes place.
|
||||
|
||||
**Add privilege isolation**
|
||||
|
||||
Image processing steps that involve decompression or unpacking should be run in isolated processes (containers?) that have only the bare minimum required privileges to operate. There is no scenario where a decompression tool like `xz` should be run as root.
|
||||
|
||||
**Replace libtrust**
|
||||
|
||||
Libtrust should be replaced with [The Update Framework][16] which is explicitly designed to solve the real problems around signing software binaries. The threat model is very comprehensive and addresses many things that have not been considered in libtrust. There is a complete specification as well as a reference implementation written in Python, and I have begun work on a [Go implementation][17] and welcome contributions.
|
||||
|
||||
As part of adding TUF to Docker, a local keystore should be added that maps root keys to registry URLs so that users can have their own signing keys that are not managed by Docker, Inc.
|
||||
|
||||
I would like to note that using non-Docker, Inc hosted registries is a very poor user experience in general. Docker, Inc seems content with relegating third party registries to second class status when there is no technical reason to do so. This is a problem both for the ecosystem in general and the security of end users. A comprehensive, decentralized security model for third party registries is both necessary and desirable. I encourage Docker, Inc to take this into consideration when redesigning their security model and image verification system.
|
||||
|
||||
### Conclusion ###
|
||||
|
||||
Docker users should be aware that the code responsible for downloading images is shockingly insecure. Users should only download images whose provenance is without question. At present, this does *not* include “trusted” images hosted by Docker, Inc including the official Ubuntu and other base images.
|
||||
|
||||
The best option is to block `index.docker.io` locally, and download and verify images manually before importing them into Docker using `docker load`. Red Hat’s security blog has [a good post about this][18].
|
||||
|
||||
Thanks to Lewis Marshall for pointing out the tarsums are never verified.
|
||||
|
||||
- [Checksum code context][19].
|
||||
- [cloc][20] says 18,141 non-blank, non-comment lines of C and 5,900 lines of headers in v5.2.0.
|
||||
- Very similar bugs been [found in Android][21], which allowed arbitrary files to be injected into signed packages, and [the Windows Authenticode][22] signature system, which allowed binary modification.
|
||||
- Specifically: [CVE-2014-6407][23], [CVE-2014-9356][24], and [CVE-2014-9357][25]. There were two Docker [security releases][26] in response.
|
||||
- See page 8 of the [notes from the 2014-10-28 DGAB meeting][27].
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://titanous.com/posts/docker-insecurity
|
||||
|
||||
作者：[titanous][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://twitter.com/titanous
|
||||
[1]:https://blog.docker.com/2014/10/docker-1-3-signed-images-process-injection-security-options-mac-shared-directories/
|
||||
[2]:https://blog.docker.com/2014/10/docker-1-3-signed-images-process-injection-security-options-mac-shared-directories/
|
||||
[3]:https://titanous.com/posts/docker-insecurity#fn:0
|
||||
[4]:https://en.wikipedia.org/wiki/Memory_safety
|
||||
[5]:https://github.com/docker/docker/blob/0874f9ab77a7957633cd835241a76ee4406196d8/pkg/archive/archive.go#L91-L95
|
||||
[6]:http://tukaani.org/xz/
|
||||
[7]:https://titanous.com/posts/docker-insecurity#fn:1
|
||||
[8]:https://github.com/docker/docker/blob/0874f9ab77a7957633cd835241a76ee4406196d8/pkg/tarsum/tarsum_spec.md
|
||||
[9]:https://titanous.com/posts/docker-insecurity#fn:2
|
||||
[10]:https://titanous.com/posts/docker-insecurity#fn:3
|
||||
[11]:https://github.com/docker/libtrust
|
||||
[12]:https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-11
|
||||
[13]:https://titanous.com/posts/docker-insecurity#fn:4
|
||||
[14]:https://github.com/docker/docker/blob/0874f9ab77a7957633cd835241a76ee4406196d8/trust/trusts.go#L38
|
||||
[15]:https://github.com/docker/docker/issues/9719
|
||||
[16]:http://theupdateframework.com/
|
||||
[17]:https://github.com/flynn/go-tuf
|
||||
[18]:https://securityblog.redhat.com/2014/12/18/before-you-initiate-a-docker-pull/
|
||||
[19]:https://github.com/docker/docker/blob/0874f9ab77a7957633cd835241a76ee4406196d8/image/image.go#L114-L116
|
||||
[20]:http://cloc.sourceforge.net/
|
||||
[21]:http://www.saurik.com/id/17
|
||||
[22]:http://blogs.technet.com/b/srd/archive/2013/12/10/ms13-098-update-to-enhance-the-security-of-authenticode.aspx
|
||||
[23]:https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6407
|
||||
[24]:https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-9356
|
||||
[25]:https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-9357
|
||||
[26]:https://groups.google.com/d/topic/docker-user/nFAz-B-n4Bw/discussion
|
||||
[27]:https://docs.google.com/document/d/1JfWNzfwptsMgSx82QyWH_Aj0DRKyZKxYQ1aursxNorg/edit?pli=1
|
||||
@ -6,7 +6,7 @@
|
||||
|
||||
虽然对于本教程，我只会演示怎样来添加**64位**网络安装镜像，但对于Ubuntu或者Debian的**32位**系统，或者其它架构的镜像，操作步骤也基本相同。同时，就我而言，我会解释添加Ubuntu 32位源的方法，但不会演示配置。
|
||||
|
||||
从PXE服务器安装 **Ubuntu**或者**Debian**要求你的客户机必须激活网络连接，最好是使用**DHCP**通过**NAT**来进行动态分配地址。以便安装器拉取需求包并完成安装进程。
|
||||
从PXE服务器安装 **Ubuntu**或者**Debian**要求你的客户机必须激活网络连接，最好是使用**DHCP**通过**NAT**来进行动态分配地址。以便安装器拉取所需的包并完成安装过程。
|
||||
|
||||
#### 需求 ####
|
||||
|
||||
@ -14,11 +14,11 @@
|
||||
|
||||
## 步骤 1： 添加Ubuntu 14.10和Ubuntu 14.04服务器到PXE菜单 ##
|
||||
|
||||
**1.** 为**Ubuntu 14.10**何**Ubuntu 14.04**添加网络安装源到PXE菜单可以通过两种方式实现：其一是通过下载Ubuntu CD ISO镜像并挂载到PXE服务器机器上以便可以读取Ubuntu网络启动文件，其二是通过直接下载Ubuntu网络启动归档包并将其解压缩到系统中。下面，我将进一步讨论这两种方法：
|
||||
**1.** 为**Ubuntu 14.10**和**Ubuntu 14.04**添加网络安装源到PXE菜单可以通过两种方式实现：其一是通过下载Ubuntu CD ISO镜像并挂载到PXE服务器机器上以便可以读取Ubuntu网络启动文件，其二是通过直接下载Ubuntu网络启动归档包并将其解压缩到系统中。下面，我将进一步讨论这两种方法：
|
||||
|
||||
### 使用Ubuntu 14.10和Ubuntu 14.04 CD ISO镜像 ###
|
||||
|
||||
为了能使用此方法，你的PXE服务器需要有一台可工作的CD/DVD驱动器。在一台专有计算机上，转到[Ubuntu 14.10下载][2]和[Ubuntu 14.04 下载][3]页，抓取64位**服务器安装镜像**，将它烧录到CD，并将CD镜像放到PXE服务器DVD/CD驱动器，然后使用以下命令挂载到系统。
|
||||
为了能使用此方法，你的PXE服务器需要有一台可工作的CD/DVD驱动器。在一台专有计算机上，转到[Ubuntu 14.10下载][2]和[Ubuntu 14.04 下载][3]页，获取64位**服务器安装镜像**，将它烧录到CD，并将CD镜像放到PXE服务器DVD/CD驱动器，然后使用以下命令挂载到系统。
|
||||
|
||||
# mount /dev/cdrom /mnt
|
||||
|
||||
@ -26,28 +26,28 @@
|
||||
|
||||
#### 在Ubuntu 14.10上 ####
|
||||
|
||||
------------------ 32位上 ------------------
|
||||
------------------ 32位 ------------------
|
||||
|
||||
# wget http://releases.ubuntu.com/14.10/ubuntu-14.10-server-i386.iso
|
||||
# mount -o loop /path/to/ubuntu-14.10-server-i386.iso /mnt
|
||||
|
||||
----------
|
||||
|
||||
------------------ 64位上 ------------------
|
||||
------------------ 64位 ------------------
|
||||
|
||||
# wget http://releases.ubuntu.com/14.10/ubuntu-14.10-server-amd64.iso
|
||||
# mount -o loop /path/to/ubuntu-14.10-server-amd64.iso /mnt
|
||||
|
||||
#### 在Ubuntu 14.04上 ####
|
||||
|
||||
------------------ 32位上 ------------------
|
||||
------------------ 32位 ------------------
|
||||
|
||||
# wget http://releases.ubuntu.com/14.04/ubuntu-14.04.1-server-i386.iso
|
||||
# mount -o loop /path/to/ubuntu-14.04.1-server-i386.iso /mnt
|
||||
|
||||
----------
|
||||
|
||||
------------------ 64位上 ------------------
|
||||
------------------ 64位 ------------------
|
||||
|
||||
# wget http://releases.ubuntu.com/14.04/ubuntu-14.04.1-server-amd64.iso
|
||||
# mount -o loop /path/to/ubuntu-14.04.1-server-amd64.iso /mnt
|
||||
@ -58,33 +58,33 @@
|
||||
|
||||
#### 在Ubuntu 14.04上 ####
|
||||
|
||||
------------------ 32位上 ------------------
|
||||
------------------ 32位 ------------------
|
||||
|
||||
# cd
|
||||
# wget http://archive.ubuntu.com/ubuntu/dists/utopic/main/installer-i386/current/images/netboot/netboot.tar.gz
|
||||
|
||||
----------
|
||||
|
||||
------------------ 64位上 ------------------
|
||||
------------------ 64位 ------------------
|
||||
|
||||
# cd
|
||||
# http://archive.ubuntu.com/ubuntu/dists/utopic/main/installer-amd64/current/images/netboot/netboot.tar.gz
|
||||
|
||||
#### 在Ubuntu 14.04上 ####
|
||||
|
||||
------------------ 32位上 ------------------
|
||||
------------------ 32位 ------------------
|
||||
|
||||
# cd
|
||||
# wget http://archive.ubuntu.com/ubuntu/dists/trusty-updates/main/installer-i386/current/images/netboot/netboot.tar.gz
|
||||
|
||||
----------
|
||||
|
||||
------------------ 64位上 ------------------
|
||||
------------------ 64位 ------------------
|
||||
|
||||
# cd
|
||||
# wget http://archive.ubuntu.com/ubuntu/dists/trusty-updates/main/installer-amd64/current/images/netboot/netboot.tar.gz
|
||||
|
||||
对于其它处理器架构，请访问下面的Ubuntu 14.10和Ubuntu 14.04网络启动官方页面，选择你的架构类型并下载需求文件。
|
||||
对于其它处理器架构，请访问下面的Ubuntu 14.10和Ubuntu 14.04网络启动官方页面，选择你的架构类型并下载所需文件。
|
||||
|
||||
- [http://cdimage.ubuntu.com/netboot/14.10/][4]
|
||||
- [http://cdimage.ubuntu.com/netboot/14.04/][5]
|
||||
@ -101,7 +101,7 @@
|
||||
# tar xfz netboot.tar.gz
|
||||
# cp -rf ubuntu-installer/ /var/lib/tftpboot/
|
||||
|
||||
如果你想要在PXE服务器上同时使用两种Ubuntu服务器架构，先请下载，然后根据不同的情况挂载并解压缩32位并拷贝**ubuntu-installer**目录到**/var/lib/tftpboot**，然后卸载CD或删除网络启动归档以及解压缩的文件和文件夹。对于64位架构，请重复上述步骤，以便让最终的**tftp**路径形成以下结构。
|
||||
如果你想要在PXE服务器上同时使用两种Ubuntu服务器架构，先请下载，然后根据不同的情况挂载或解压缩32位架构，然后拷贝**ubuntu-installer**目录到**/var/lib/tftpboot**，然后卸载CD或删除网络启动归档以及解压缩的文件和文件夹。对于64位架构，请重复上述步骤，以便让最终的**tftp**路径形成以下结构。
|
||||
|
||||
/var/lib/tftpboot/ubuntu-installer/amd64
|
||||
/var/lib/tftpboot/ubuntu-installer/i386
|
||||
@ -238,7 +238,7 @@ via: http://www.tecmint.com/add-ubuntu-to-pxe-network-boot/
|
||||
|
||||
作者：[Matei Cezar][a]
|
||||
译者：[GOLinux](https://github.com/GOLinux)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[Mr小眼儿](https://github.com/tinyeyeser)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
|
||||
135
translated/tech/20150104 Docker Image Insecurity.md
Normal file
135
translated/tech/20150104 Docker Image Insecurity.md
Normal file
@ -0,0 +1,135 @@
|
||||
Docker的镜像并不安全！
|
||||
================================================================================
|
||||
最近使用Docker下载“官方”容器镜像的时候，我发现这样一句话：
|
||||
|
||||
ubuntu:14.04: The image you are pulling has been verified （您所拉取的镜像已经经过验证）
|
||||
|
||||
起初我以为这条信息引自Docker[大力推广][1]的镜像签名系统，因此也就没有继续跟进。后来，研究加密摘要系统的时候——Docker用这套系统来对镜像进行安全加固——我才有机会更深入的发现，逻辑上整个与镜像安全相关的部分具有一系列系统性问题。
|
||||
|
||||
Docker所报告的，一个已下载的镜像经过“验证”，它基于的仅仅是一个标记清单（signed manifest)，而Docker却从未根据清单对镜像的校验和进行验证。一名攻击者以此可以提供任意所谓具有标记清单的镜像。一系列严重漏洞的大门就此敞开。
|
||||
|
||||
镜像经由HTTPS服务器下载后，通过一个未加密的管道流进入Docker守护进程：
|
||||
|
||||
[decompress] -> [tarsum] -> [unpack]
|
||||
|
||||
这条管道的性能没有问题，但是却完全没有经过加密。不可信的输入在签名验证之前是不应当进入管道的。不幸的是，Docker在上面处理镜像的三个步骤中，都没有对校验和进行验证。
|
||||
|
||||
然而，不论Docker如何[声明][2]，实际上镜像的校验和从未经过校验。下面是Docker与镜像校验和的验证相关的代码[片段][3]，即使我提交了校验和不匹配的镜像，都无法触发警告信息。
|
||||
|
||||
if img.Checksum != "" && img.Checksum != checksum {
|
||||
log.Warnf("image layer checksum mismatch: computed %q,
|
||||
expected %q", checksum, img.Checksum)
|
||||
}
|
||||
|
||||
### 不安全的处理管道 ###
|
||||
|
||||
**解压缩**
|
||||
|
||||
Docker支持三种压缩算法：gzip、bzip2和xz。前两种使用Go的标准库实现，是[内存安全（memory-safe)][4]的，因此这里我预计的攻击类型应该是拒绝服务类的攻击，包括CPU和内存使用上的当机或过载等等。
|
||||
|
||||
第三种压缩算法，xz，比较有意思。因为没有现成的Go实现，Docker 通过[执行(exec)][5]`xz`二进制命令来实现解压缩。
|
||||
|
||||
xz二进制程序来自于[XZ Utils][6]项目，由[大概][7]2万行C代码生成而来。而C语言不是一门内存安全的语言。这意味着C程序的恶意输入，在这里也就是Docker镜像的XZ Utils解包程序，潜在地可能会执行任意代码。
|
||||
|
||||
Docker以root权限*运行* `xz` 命令，更加恶化了这一潜在威胁。这意味着如果在`xz`中出现了一个漏洞，对`docker pull`命令的调用就会导致用户整个系统的完全沦陷。
|
||||
|
||||
**Tarsum**
|
||||
|
||||
对tarsum的使用，其出发点是好的，但却是最大的败笔。为了得到任意一个加密tar文件的准确校验和，Docker先对tar文件进行解密，然后求出特定部分的哈希值，同时排除剩余的部分，而这些步骤的[顺序都是固定的][8]。
|
||||
|
||||
由于其生成校验和的步骤固定，它解码不可信数据的过程就有可能被设计成[攻破tarsum的代码][9]。这里潜在的攻击既包括拒绝服务攻击，还有逻辑上的漏洞攻击，可能导致文件被感染、忽略、进程被篡改、植入等等，这一切攻击的同时，校验和可能都是不变的。
|
||||
|
||||
|
||||
**解包**
|
||||
|
||||
解包的过程包括tar解码和生成硬盘上的文件。这一过程尤其危险，因为在解包写入硬盘的过程中有另外三个[已报告的漏洞][10]。
|
||||
|
||||
任何情形下未经验证的数据都不应当解包后直接写入硬盘。
|
||||
|
||||
### libtrust ###
|
||||
|
||||
Docker的工具包[libtrust][11]，号称“通过一个分布式的信任图表进行认证和访问控制”。很不幸，对此官方没有任何具体的说明，看起来它好像是实现了一些[javascript对象标记和加密][12]规格以及其他一些未说明的算法。
|
||||
|
||||
使用libtrust下载一个清单经过签名和认证的镜像，就可以触发下面这条不准确的信息（说不准确，是因为事实上它验证的只是清单，并非真正的镜像）：
|
||||
|
||||
ubuntu:14.04: The image you are pulling has been verified(您所拉取的镜像已经经过验证)
|
||||
|
||||
目前只有Docker公司“官方”发布的镜像清单使用了这套签名系统，但是上次我参加Docker[管理咨询委员会][13]的会议讨论时，我所理解的是，Docker公司正计划在未来扩大部署这套系统。他们的目标是以Docker公司为中心，控制一个认证授权机构，对镜像进行签名和（或）客户认证。
|
||||
|
||||
我试图从Docker的代码中找到签名秘钥，但是没找到。好像它并不像我们所期望的把密钥嵌在二进制代码中，而是在每次镜像下载前，由Docker守护进程[通过HTTPS从CDN][14]远程获取。这是一个多么糟糕的方案，有无数种攻击手段可能会将可信密钥替换成恶意密钥。这些攻击包括但不限于：CDN供应商出问题、CDN初始密钥出现问题、客户端下载时的中间人攻击等等。
|
||||
|
||||
### 补救 ###
|
||||
|
||||
研究结束前，我[报告][15]了一些在tarsum系统中发现的问题，但是截至目前我报告的这些问题仍然
|
||||
没有修复。
|
||||
|
||||
要改进Docker镜像下载系统的安全问题，我认为应当有以下措施：
|
||||
|
||||
**摒弃tarsum并且真正对镜像本身进行验证**
|
||||
|
||||
出于安全原因tarsum应当被摒弃，同时，镜像在完整下载后、其他步骤开始前，就对镜像的加密签名进行验证。
|
||||
|
||||
**添加权限隔离**
|
||||
|
||||
镜像的处理过程中涉及到解压缩或解包的步骤必须在隔离的进程（容器？）中进行，即只给予其操作所需的最小权限。任何场景下都不应当使用root运行`xz`这样的解压缩工具。
|
||||
|
||||
**替换 libtrust**
|
||||
|
||||
应当用[更新框架(The Update Framework)][16]替换掉libtrust，这是专门设计用来解决软件二进制签名此类实际问题的。其威胁模型非常全方位，能够解决libtrust中未曾考虑到的诸多问题，目前已经有了完整的说明文档。除了已有的Python实现，我已经开始着手用[Go语言实现][17]的工作，也欢迎大家的贡献。
|
||||
|
||||
作为将更新框架加入Docker的一部分，还应当加入一个本地密钥存储池，将root密钥与registry的地址进行映射，这样用户就可以拥有他们自己的签名密钥，而不必使用Docker公司的了。
|
||||
|
||||
我注意到使用Docker公司非官方的宿主仓库往往会是一种非常糟糕的用户体验。当没有技术上的原因时，Docker也会将第三方的仓库内容降为二等地位来看待。这个问题不仅仅是生态问题，还是一个终端用户的安全问题。针对第三方仓库的全方位、去中心化的安全模型即必须又迫切。我希望Docker公司在重新设计他们的安全模型和镜像认证系统时能采纳这一点。
|
||||
|
||||
### 结论 ###
|
||||
|
||||
Docker用户应当意识到负责下载镜像的代码是非常不安全的。用户们应当只下载那些出处没有问题的镜像。目前，这里的“没有问题”并不包括Docker公司的“可信（trusted）”镜像，例如官方的Ubuntu和其他基础镜像。
|
||||
|
||||
最好的选择就是在本地屏蔽 `index.docker.io`，然后使用`docker load`命令在导入Docker之前手动下载镜像并对其进行验证。Red Hat的安全博客有一篇[很好的文章][18]，大家可以看看。
|
||||
|
||||
感谢Lewis Marshall指出tarsum从未真正验证。
|
||||
|
||||
- [校验和的代码][19]
|
||||
- [cloc][20]介绍了18141行没有空格没有注释的C代码，以及5900行的header代码，版本号为v5.2.0。
|
||||
- [Android中也发现了][21]类似的bug，能够感染已签名包中的任意文件。同样出现问题的还有[Windows的Authenticode][22]认证系统，二进制文件会被篡改。
|
||||
- 特别的：[CVE-2014-6407][23]、 [CVE-2014-9356][24]以及 [CVE-2014-9357][25]。目前已有两个Docker[安全发布][26]有了回应。
|
||||
- 参见[2014-10-28 DGAB会议记录][27]的第8页。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://titanous.com/posts/docker-insecurity
|
||||
|
||||
作者：[titanous][a]
|
||||
译者：[Mr小眼儿](http://blog.csdn.net/tinyeyeser)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://twitter.com/titanous
|
||||
[1]:https://blog.docker.com/2014/10/docker-1-3-signed-images-process-injection-security-options-mac-shared-directories/
|
||||
[2]:https://blog.docker.com/2014/10/docker-1-3-signed-images-process-injection-security-options-mac-shared-directories/
|
||||
[3]:https://titanous.com/posts/docker-insecurity#fn:0
|
||||
[4]:https://en.wikipedia.org/wiki/Memory_safety
|
||||
[5]:https://github.com/docker/docker/blob/0874f9ab77a7957633cd835241a76ee4406196d8/pkg/archive/archive.go#L91-L95
|
||||
[6]:http://tukaani.org/xz/
|
||||
[7]:https://titanous.com/posts/docker-insecurity#fn:1
|
||||
[8]:https://github.com/docker/docker/blob/0874f9ab77a7957633cd835241a76ee4406196d8/pkg/tarsum/tarsum_spec.md
|
||||
[9]:https://titanous.com/posts/docker-insecurity#fn:2
|
||||
[10]:https://titanous.com/posts/docker-insecurity#fn:3
|
||||
[11]:https://github.com/docker/libtrust
|
||||
[12]:https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-11
|
||||
[13]:https://titanous.com/posts/docker-insecurity#fn:4
|
||||
[14]:https://github.com/docker/docker/blob/0874f9ab77a7957633cd835241a76ee4406196d8/trust/trusts.go#L38
|
||||
[15]:https://github.com/docker/docker/issues/9719
|
||||
[16]:http://theupdateframework.com/
|
||||
[17]:https://github.com/flynn/go-tuf
|
||||
[18]:https://securityblog.redhat.com/2014/12/18/before-you-initiate-a-docker-pull/
|
||||
[19]:https://github.com/docker/docker/blob/0874f9ab77a7957633cd835241a76ee4406196d8/image/image.go#L114-L116
|
||||
[20]:http://cloc.sourceforge.net/
|
||||
[21]:http://www.saurik.com/id/17
|
||||
[22]:http://blogs.technet.com/b/srd/archive/2013/12/10/ms13-098-update-to-enhance-the-security-of-authenticode.aspx
|
||||
[23]:https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6407
|
||||
[24]:https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-9356
|
||||
[25]:https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-9357
|
||||
[26]:https://groups.google.com/d/topic/docker-user/nFAz-B-n4Bw/discussion
|
||||
[27]:https://docs.google.com/document/d/1JfWNzfwptsMgSx82QyWH_Aj0DRKyZKxYQ1aursxNorg/edit?pli=1
|
||||
Loading…
Reference in New Issue
Block a user