Kubernetes所使用的其中一個(gè)Go代碼庫中存在漏洞，該漏洞可能會(huì)導(dǎo)致CRI-O和Podman容器引擎的拒絕服務(wù)攻擊。

該漏洞(CVE-2021-20291)會(huì)影響一個(gè)名為 "containers/storage "的Go語言代碼庫。據(jù)發(fā)現(xiàn)該漏洞的Unit 42團(tuán)隊(duì)的安全研究員Aviv Sasson介紹，該漏洞可以通過在注冊(cè)表內(nèi)放置一個(gè)惡意鏡像來觸發(fā);當(dāng)該鏡像被惡意攻擊者從注冊(cè)表中調(diào)出時(shí)，就可以進(jìn)行DoS攻擊。

[[396775]]

Sasson在周三的一篇文章中說:"通過這個(gè)漏洞，惡意攻擊者可能會(huì)攻擊包括Kubernetes和OpenShift在內(nèi)的任何一個(gè)依賴有漏洞的容器引擎的基礎(chǔ)設(shè)施"

CRI-O和Podman都是容器引擎，類似于Docker，主要用于在云端執(zhí)行操作和管理容器。CRI-O和Podman使用”containers/storage”來處理容器鏡像的存儲(chǔ)和下載。

研究人員稱，當(dāng)該漏洞被觸發(fā)時(shí)，CRI-O就無法拉取新的鏡像、啟動(dòng)任何新的容器(即使它們已經(jīng)被拉取到本地)、檢索本地鏡像列表或停止容器運(yùn)行。

同樣，Podman也將無法拉取新的鏡像，檢索正在運(yùn)行的pods，啟動(dòng)新的容器(即使它們已經(jīng)被拉取到本地)，檢索現(xiàn)有的鏡像或終止所有的容器。

這個(gè)漏洞影響可能非常廣泛。Sasson解釋說:"從Kubernetes v1.20開始，Docker就已經(jīng)被廢棄使用，現(xiàn)在唯一支持的容器引擎是CRI-O和 Containerd，這就導(dǎo)致了很多集群使用CRI-O。在實(shí)際的攻擊場(chǎng)景中，攻擊者可能會(huì)將一個(gè)惡意鏡像拉到多個(gè)不同的節(jié)點(diǎn)上，使所有節(jié)點(diǎn)崩潰，破壞集群。而除了重新啟動(dòng)節(jié)點(diǎn)外，目前沒有任何解決問題的方法。"

容器武器化

當(dāng)容器引擎從注冊(cè)表中提取一個(gè)鏡像時(shí)，它首先會(huì)下載清單，其中會(huì)含有關(guān)于如何構(gòu)建映像的說明。其中一部分是組成容器文件系統(tǒng)的層列表，容器引擎會(huì)讀取該列表，然后下載并解壓每個(gè)層。

Sasson解釋說："攻擊者可以向注冊(cè)表中上傳一個(gè)可以利用該漏洞的惡意層，然后上傳一個(gè)使用眾多層的鏡像，包括惡意層，并借此創(chuàng)建一個(gè)新的惡意鏡像。然后，當(dāng)受害者從注冊(cè)表中提取鏡像時(shí)，它將會(huì)在該過程中下載惡意層，從而完成該漏洞的利用。"

一旦容器引擎開始下載惡意層，最終的結(jié)果就是發(fā)生死鎖。

Sasson解釋說："在這種情況下，進(jìn)程會(huì)獲取到鎖，并且這個(gè)鎖永遠(yuǎn)都不會(huì)被釋放，這將導(dǎo)致DoS發(fā)生，因?yàn)榇藭r(shí)其他線程和進(jìn)程都會(huì)停止執(zhí)行并永遠(yuǎn)等待鎖被釋放。"

他列出了該漏洞被觸發(fā)時(shí)發(fā)生的步驟。

例程1--從注冊(cè)表下載惡意層。

例程1 - 從注冊(cè)表中下載惡意層.進(jìn)程1 獲取鎖。

例程2 - 使用xz二進(jìn)制解壓下載的層，并將輸出寫入到stdout。

例程3 - 等待xz退出并讀取stdout中的所有數(shù)據(jù)。當(dāng)條件滿足時(shí)，它會(huì)關(guān)閉一個(gè)名為chdone的通道。

例程1 - 使用 xz 的輸出作為輸入，并嘗試解壓縮數(shù)據(jù)。由于文件不是 tar 存檔文件，untar 會(huì)出現(xiàn)"invalid tar header "報(bào)錯(cuò)，并且不會(huì)從 xz 的標(biāo)準(zhǔn)輸出中讀取其余數(shù)據(jù)。由于數(shù)據(jù)永遠(yuǎn)不會(huì)被讀取，例程3現(xiàn)在是死鎖，也就永遠(yuǎn)不會(huì)關(guān)閉chdone。

例程1 - 等待例程3關(guān)閉chdone，也是死鎖。

一旦例程1被死鎖，容器引擎就無法執(zhí)行任何新的請(qǐng)求，因?yàn)槿绻獔?zhí)行新的請(qǐng)求，它需要獲取步驟2的鎖，而這個(gè)鎖永遠(yuǎn)都不會(huì)被釋放。

containers/storage的1.28.1版本、CRI-O的v1.20.2版本和Podman的3.1.0版本都發(fā)布了該bug的補(bǔ)丁。管理員應(yīng)盡快更新。

容器安全成為了焦點(diǎn)

云容器仍然是網(wǎng)絡(luò)攻擊者的攻擊的重點(diǎn)。例如，4月早些時(shí)候就發(fā)現(xiàn)了一個(gè)有組織的、進(jìn)行廣泛攻擊的密碼竊取活動(dòng)，其攻擊目標(biāo)是配置錯(cuò)誤的開放的Docker Daemon API端口。每天都可以觀察到數(shù)千次與該活動(dòng)相關(guān)的攻擊。

研究人員表示，同樣是在4月份，在微軟的云容器技術(shù)Azure Functions中發(fā)現(xiàn)存在一個(gè)漏洞，該漏洞允許攻擊者直接寫入文件。這是一個(gè)權(quán)限升級(jí)漏洞，最終可能讓攻擊者實(shí)現(xiàn)容器逃逸。

而在最近的一次實(shí)驗(yàn)室測(cè)試中，一個(gè)簡(jiǎn)單的Docker容器蜜罐在24小時(shí)內(nèi)發(fā)生了四次不同的網(wǎng)絡(luò)攻擊，這是一個(gè)很直接的例子，可以說明為什么云基礎(chǔ)設(shè)施需要強(qiáng)大的安全性。

本文翻譯自：https://threatpost.com/security-bug-brick-kubernetes-clusters/165413/