Kubernetes所使用的其中一個Go代碼庫中存在漏洞，該漏洞可能會導致CRI-O和Podman容器引擎的拒絕服務攻擊。

該漏洞(CVE-2021-20291)會影響一個名為 "containers/storage "的Go語言代碼庫。據發(fā)現該漏洞的Unit 42團隊的安全研究員Aviv Sasson介紹，該漏洞可以通過在注冊表內放置一個惡意鏡像來觸發(fā);當該鏡像被惡意攻擊者從注冊表中調出時，就可以進行DoS攻擊。

[[396775]]

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

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

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

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

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

容器武器化

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

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

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

Sasson解釋說："在這種情況下，進程會獲取到鎖，并且這個鎖永遠都不會被釋放，這將導致DoS發(fā)生，因為此時其他線程和進程都會停止執(zhí)行并永遠等待鎖被釋放。"

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

例程1--從注冊表下載惡意層。

例程1 - 從注冊表中下載惡意層.進程1 獲取鎖。

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

例程3 - 等待xz退出并讀取stdout中的所有數據。當條件滿足時，它會關閉一個名為chdone的通道。

例程1 - 使用 xz 的輸出作為輸入，并嘗試解壓縮數據。由于文件不是 tar 存檔文件，untar 會出現"invalid tar header "報錯，并且不會從 xz 的標準輸出中讀取其余數據。由于數據永遠不會被讀取，例程3現在是死鎖，也就永遠不會關閉chdone。

例程1 - 等待例程3關閉chdone，也是死鎖。

一旦例程1被死鎖，容器引擎就無法執(zhí)行任何新的請求，因為如果要執(zhí)行新的請求，它需要獲取步驟2的鎖，而這個鎖永遠都不會被釋放。

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

容器安全成為了焦點

云容器仍然是網絡攻擊者的攻擊的重點。例如，4月早些時候就發(fā)現了一個有組織的、進行廣泛攻擊的密碼竊取活動，其攻擊目標是配置錯誤的開放的Docker Daemon API端口。每天都可以觀察到數千次與該活動相關的攻擊。

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

而在最近的一次實驗室測試中，一個簡單的Docker容器蜜罐在24小時內發(fā)生了四次不同的網絡攻擊，這是一個很直接的例子，可以說明為什么云基礎設施需要強大的安全性。

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