最近在使用Docker下載一個(gè)“官方”容器鏡像時(shí)我看到這么一行提示：

我當(dāng)時(shí)以為這和Docker極力推薦的鏡像簽名系統(tǒng)有關(guān)，所以并未深究。后來(lái)，在研究Docker鏡像安全相關(guān)的加密系統(tǒng)時(shí)，我開(kāi)始進(jìn)一步探索Docker的鏡像安全。而我發(fā)現(xiàn)所有與鏡像安全相關(guān)的邏輯完全是系統(tǒng)性的錯(cuò)誤。

按照Docker的說(shuō)法，下載的鏡像完全是基于簽名的manifest的存在而做出的，并且Docker并沒(méi)有從manifest中校驗(yàn)鏡像的校驗(yàn)和（checksum）。攻擊者可以偽造提供一個(gè)具有簽名證明的鏡像，這個(gè)問(wèn)題很容易被攻擊者利用。

鏡像從HTTPS服務(wù)器上下載下來(lái)，然后通過(guò)Docker daemon的一個(gè)不安全的流處理管道：

這個(gè)管道很高效，但毫無(wú)安全可言。在未驗(yàn)證簽名之前，管道不應(yīng)該處理不受信任的輸入。然而，在驗(yàn)證檢驗(yàn)和之前，Docker進(jìn)行了三次鏡像的處理。

盡管Docker做了聲明，但它從未實(shí)際檢查過(guò)鏡像校驗(yàn)。下面是Docker中唯一一處與驗(yàn)證鏡像校驗(yàn)和有關(guān)的代碼，但是即便在鏡像中提供不匹配的校驗(yàn)和，我也無(wú)法觸發(fā)這個(gè)警告。

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

不安全的處理管道

解壓縮

Docker支持三種壓縮算法：gzip、bzip2和xz。前兩者使用Go的標(biāo)準(zhǔn)庫(kù)實(shí)現(xiàn)，這是內(nèi)存安全的，所以我能想到的漏洞類型是拒絕服務(wù)攻擊，如宕機(jī)、CPU和內(nèi)存過(guò)度使用。

第三個(gè)壓縮算法xz更有趣。因?yàn)闆](méi)有原生的Go實(shí)現(xiàn)，Docker運(yùn)行xz程序來(lái)解壓縮。

xz程序來(lái)自XZ Utils項(xiàng)目，它從接近2萬(wàn)行C代碼中構(gòu)建而來(lái)。C不是一個(gè)內(nèi)存安全的語(yǔ)言。這意味著一個(gè)C程序的惡意輸入，此處為XZ Utils正在解包的Docker鏡像，有執(zhí)行任意的代碼的可能。

如果Docker以root運(yùn)行xz，那會(huì)更糟糕，這意味著如果xz存在一個(gè)漏洞，執(zhí)行docker pull將嚴(yán)重危及你的整個(gè)系統(tǒng)。

Tarsum

tarsum的使用出于好意，但完全錯(cuò)誤。為了取得一個(gè)任意編碼的tar文件的確定性校驗(yàn)和，Docker對(duì)tar進(jìn)行解碼然后以確定性順序?qū)μ囟ú糠诌M(jìn)行哈希，排除了其他部分。

因?yàn)檫@個(gè)處理過(guò)程是為了生成校驗(yàn)和，它正在解碼的不受信任的數(shù)據(jù)可被設(shè)計(jì)成利用tarsum代碼的漏洞。這里可能的漏洞是拒絕服務(wù)攻擊以及邏輯缺陷，這將引起文件在不改變校驗(yàn)和的情況下被注入、跳過(guò)、使用不同方式處理、修改、添加等。

解包

解包分為tar解碼和將文件到保存到硬盤中兩個(gè)步驟，在編寫(xiě)本文的時(shí)候已經(jīng)有解包階段的三個(gè)其他漏洞被報(bào)告出來(lái)，所以這也是非常危險(xiǎn)的。

不應(yīng)該存在未被檢驗(yàn)的數(shù)據(jù)被解包到硬盤中的情況。

libtrust

libtrust是一個(gè)提供認(rèn)證和權(quán)限控制的Docker包。但是官方?jīng)]有提供任何的規(guī)范，但它看起來(lái)像是實(shí)現(xiàn)了Javascript對(duì)象簽名與加密規(guī)范的一部分，以及其他不明算法。

所以在下載一個(gè)manifest簽名的以及使用libtrust驗(yàn)證的鏡像時(shí)，會(huì)有如下不準(zhǔn)確的提示：

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

目前只有Docker公司公布的“官方”鏡像manifest使用這個(gè)系統(tǒng)簽名，但從我參加的最近一次Docker管理咨詢委員會(huì)會(huì)議的討論看來(lái)，Docker公司計(jì)劃在未來(lái)更廣泛的部署它。目標(biāo)應(yīng)該是集中管理，由Docker公司控制一個(gè)發(fā)證機(jī)構(gòu)用于鏡像和/或客戶證明簽名。

我曾在Docker代碼中查找簽名密鑰，但沒(méi)找到?？磥?lái)密鑰并沒(méi)有嵌入到程序中。實(shí)際上，Docker后臺(tái)會(huì)在每次鏡像下載時(shí)通過(guò)HTTPS從CDN獲取密鑰。這是一個(gè)非常糟糕的方式，因?yàn)橛泻芏喾N攻擊可以導(dǎo)致受信任的密鑰被替換成惡意的。這種攻擊包括但不限于：CDN供應(yīng)商威脅、CDN供應(yīng)密鑰源威脅以及客戶端下載密鑰時(shí)的中間人攻擊。

補(bǔ)救

在完成此項(xiàng)研究之前，我已經(jīng)報(bào)告了我發(fā)現(xiàn)的tarsum系統(tǒng)的幾個(gè)問(wèn)題，但至今沒(méi)有一個(gè)被修復(fù)。

我覺(jué)得必須采取一些措施來(lái)改善Docker鏡像下載系統(tǒng)的安全性：

棄用tarsum并實(shí)際驗(yàn)證鏡像摘要

為安全起見(jiàn)，不應(yīng)該使用tarsum。取而代之的是在進(jìn)行任何處理前，將鏡像完全下載并對(duì)其加密簽名進(jìn)行驗(yàn)證。

增加權(quán)限隔離

涉及解壓縮或解包的鏡像處理步驟必須運(yùn)行于具有最低限度的必要的權(quán)限的隔離的程序（容器？）中。不應(yīng)該存在像xz這樣的解壓縮工具必須以root運(yùn)行的情況。

更換libtrust

用The Update Framework替換libtrust，前者是明確設(shè)計(jì)用于解決軟件程序簽名的實(shí)際問(wèn)題的。它的威脅模型非常全面，并且解決了很多l(xiāng)ibtrust沒(méi)有考慮到的事情。它擁有一個(gè)完整的規(guī)范，以及一個(gè)Python的參考實(shí)現(xiàn)，我已經(jīng)開(kāi)始Go的實(shí)現(xiàn)并且歡迎任何人加入。

作為添加TUF到Docker的一部分，一個(gè)映射根密鑰到registry URL的本地密鑰庫(kù)將被加入，以便用戶可以使用不受Docker公司管理的自有簽名密鑰。

我想指出的是，一般情況下使用非Docker公司托管的registry用戶體驗(yàn)非常差。在沒(méi)有任何技術(shù)原因的情況下，Docker公司似乎樂(lè)于將第三方registry降低為二等地位。這對(duì)一般的生態(tài)系統(tǒng)和最終用戶的安全來(lái)說(shuō)都是個(gè)問(wèn)題。綜合而言，針對(duì)第三方registry的分散的安全模型是必要和可取的。我非常期待Docker公司在重新設(shè)計(jì)他們的安全模型和鏡像驗(yàn)證系統(tǒng)時(shí)考慮這一點(diǎn)。

結(jié)論

Docker用戶應(yīng)該清楚負(fù)責(zé)下載鏡像的代碼是極其不安全的。用戶只能下載那些來(lái)源沒(méi)有問(wèn)題的鏡像。目前，這不包括托管于Docker公司的“可信的”的鏡像，包括官方的Ubuntu和其他基礎(chǔ)鏡像。

最好的辦法是在本地阻止index.docker.io，并在鏡像導(dǎo)入到Docker之前手動(dòng)使用docker load下載并檢驗(yàn)鏡像。Red Hat的安全博客有篇與此相關(guān)的好文章。

感謝Lewis Marshall指出tarsum從未被驗(yàn)證。

原文：《Docker Image Insecurity》

本文出自：http://dockerone.com/article/77