改善 Docker 鏡像系統(tǒng)安全性的補救措施
最近在使用Docker下載一個“官方”容器鏡像時我看到這么一行提示：
| ubuntu:14.04: The image you are pulling has been verified |
我當(dāng)時以為這和Docker極力推薦的鏡像簽名系統(tǒng)有關(guān)，所以并未深究。后來，在研究Docker鏡像安全相關(guān)的加密系統(tǒng)時，我開始進一步探索Docker的鏡像安全。而我發(fā)現(xiàn)所有與鏡像安全相關(guān)的邏輯完全是系統(tǒng)性的錯誤。
按照Docker的說法，下載的鏡像完全是基于簽名的manifest的存在而做出的，并且Docker并沒有從manifest中校驗鏡像的校驗和（checksum）。攻擊者可以偽造提供一個具有簽名證明的鏡像，這個問題很容易被攻擊者利用。
鏡像從HTTPS服務(wù)器上下載下來，然后通過Docker daemon的一個不安全的流處理管道：
| [解壓縮] -> [tarsum] -> [解包] |
這個管道很高效，但毫無安全可言。在未驗證簽名之前，管道不應(yīng)該處理不受信任的輸入。然而，在驗證檢驗和之前，Docker進行了三次鏡像的處理。
盡管Docker做了聲明，但它從未實際檢查過鏡像校驗。下面是Docker中唯一一處與驗證鏡像校驗和有關(guān)的代碼，但是即便在鏡像中提供不匹配的校驗和，我也無法觸發(fā)這個警告。
- 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)庫實現(xiàn)，這是內(nèi)存安全的，所以我能想到的漏洞類型是拒絕服務(wù)攻擊，如宕機、CPU和內(nèi)存過度使用。
第三個壓縮算法xz更有趣。因為沒有原生的Go實現(xiàn)，Docker運行xz程序來解壓縮。
xz程序來自XZ Utils項目，它從接近2萬行C代碼中構(gòu)建而來。C不是一個內(nèi)存安全的語言。這意味著一個C程序的惡意輸入，此處為XZ Utils正在解包的Docker鏡像，有執(zhí)行任意的代碼的可能。
如果Docker以root運行xz，那會更糟糕，這意味著如果xz存在一個漏洞，執(zhí)行docker pull將嚴(yán)重危及你的整個系統(tǒng)。
Tarsum
tarsum的使用出于好意，但完全錯誤。為了取得一個任意編碼的tar文件的確定性校驗和，Docker對tar進行解碼然后以確定性順序?qū)μ囟ú糠诌M行哈希，排除了其他部分。
因為這個處理過程是為了生成校驗和，它正在解碼的不受信任的數(shù)據(jù)可被設(shè)計成利用tarsum代碼的漏洞。這里可能的漏洞是拒絕服務(wù)攻擊以及邏輯缺陷，這將引起文件在不改變校驗和的情況下被注入、跳過、使用不同方式處理、修改、添加等。
解包
解包分為tar解碼和將文件到保存到硬盤中兩個步驟，在編寫本文的時候已經(jīng)有解包階段的三個其他漏洞被報告出來，所以這也是非常危險的。
不應(yīng)該存在未被檢驗的數(shù)據(jù)被解包到硬盤中的情況。
libtrust
libtrust是一個提供認證和權(quán)限控制的Docker包。但是官方?jīng)]有提供任何的規(guī)范，但它看起來像是實現(xiàn)了Javascript對象簽名與加密規(guī)范的一部分，以及其他不明算法。
所以在下載一個manifest簽名的以及使用libtrust驗證的鏡像時，會有如下不準(zhǔn)確的提示：
ubuntu:14.04: The image you are pulling has been verified
目前只有Docker公司公布的“官方”鏡像manifest使用這個系統(tǒng)簽名，但從我參加的最近一次Docker管理咨詢委員會會議的討論看來，Docker公司計劃在未來更廣泛的部署它。目標(biāo)應(yīng)該是集中管理，由Docker公司控制一個發(fā)證機構(gòu)用于鏡像和/或客戶證明簽名。
我曾在Docker代碼中查找簽名密鑰，但沒找到。看來密鑰并沒有嵌入到程序中。實際上，Docker后臺會在每次鏡像下載時通過HTTPS從CDN獲取密鑰。這是一個非常糟糕的方式，因為有很多種攻擊可以導(dǎo)致受信任的密鑰被替換成惡意的。這種攻擊包括但不限于：CDN供應(yīng)商威脅、CDN供應(yīng)密鑰源威脅以及客戶端下載密鑰時的中間人攻擊。
補救
在完成此項研究之前，我已經(jīng)報告了我發(fā)現(xiàn)的tarsum系統(tǒng)的幾個問題，但至今沒有一個被修復(fù)。
我覺得必須采取一些措施來改善Docker鏡像下載系統(tǒng)的安全性：
棄用tarsum并實際驗證鏡像摘要
為安全起見，不應(yīng)該使用tarsum。取而代之的是在進行任何處理前，將鏡像完全下載并對其加密簽名進行驗證。
增加權(quán)限隔離
涉及解壓縮或解包的鏡像處理步驟必須運行于具有最低限度的必要的權(quán)限的隔離的程序（容器？）中。不應(yīng)該存在像xz這樣的解壓縮工具必須以root運行的情況。
更換libtrust
用The Update Framework替換libtrust，前者是明確設(shè)計用于解決軟件程序簽名的實際問題的。它的威脅模型非常全面，并且解決了很多l(xiāng)ibtrust沒有考慮到的事情。它擁有一個完整的規(guī)范，以及一個Python的參考實現(xiàn)，我已經(jīng)開始Go的實現(xiàn)并且歡迎任何人加入。
作為添加TUF到Docker的一部分，一個映射根密鑰到registry URL的本地密鑰庫將被加入，以便用戶可以使用不受Docker公司管理的自有簽名密鑰。
我想指出的是，一般情況下使用非Docker公司托管的registry用戶體驗非常差。在沒有任何技術(shù)原因的情況下，Docker公司似乎樂于將第三方registry降低為二等地位。這對一般的生態(tài)系統(tǒng)和最終用戶的安全來說都是個問題。綜合而言，針對第三方registry的分散的安全模型是必要和可取的。我非常期待Docker公司在重新設(shè)計他們的安全模型和鏡像驗證系統(tǒng)時考慮這一點。
結(jié)論
Docker用戶應(yīng)該清楚負責(zé)下載鏡像的代碼是極其不安全的。用戶只能下載那些來源沒有問題的鏡像。目前，這不包括托管于Docker公司的“可信的”的鏡像，包括官方的Ubuntu和其他基礎(chǔ)鏡像。
最好的辦法是在本地阻止index.docker.io，并在鏡像導(dǎo)入到Docker之前手動使用docker load下載并檢驗鏡像。Red Hat的安全博客有篇與此相關(guān)的好文章。
感謝Lewis Marshall指出tarsum從未被驗證。
本文出自：http://dockerone.com/article/77
