幾天前 消息發布 細節已經披露 脆弱性 發現 在機制執行中 資源限制 cgroup v1 在 Linux 內核中，該內核已在 CVE-2022-0492 下編目。
發現此漏洞e 可用於退出隔離容器 並詳細說明該問題自 Linux 內核 2.6.24 以來一直存在。
在博客文章中提到 該漏洞是由於 release_agent 文件處理程序中的邏輯錯誤， 所以當驅動程序以完全權限運行時沒有執行正確的檢查。
文件 release_agent 用於定義內核執行的程序 當一個進程以 cgroup 結束時。 該程序以 root 身份運行，具有根名稱空間中的所有“功能”。 只有管理員應該有權訪問 release_agent 配置，但實際上，檢查僅限於授予 root 用戶訪問權限，這並不排除從容器或非管理員 root 用戶 (CAP_SYS_ADMIN) 更改配置.
此前， 此功能不會被視為漏洞，但是隨著用戶標識符命名空間（用戶命名空間）的出現，情況發生了變化，它允許您在不與主環境的 root 用戶重疊的容器中創建單獨的 root 用戶。
因此， 對於攻擊，在擁有自己的 root 用戶的容器中就足夠了 在單獨的用戶 ID 空間中插入您的 release_agent 處理程序，一旦該過程完成，它將以父環境的所有權限運行。
默認情況下，cgroupfs 掛載在只讀容器中，但在寫入模式下使用 CAP_SYS_ADMIN 權限重新掛載此 pseudofs 或通過使用停止共享的系統調用創建具有單獨用戶命名空間的嵌套容器沒有問題，其中 CAP_SYS_ADMIN 權限可用於創建的容器。
進攻 可以通過在隔離容器中擁有 root 權限來完成 或者通過在沒有 no_new_privs 標誌的情況下運行容器，該標誌禁止獲得額外的權限。
系統必須啟用對命名空間的支持 用戶（在 Ubuntu 和 Fedora 上默認啟用，但在 Debian 和 RHEL 上未啟用）並有權訪問根 v1 cgroup（例如，Docker 在 RDMA 根 cgroup 中運行容器）。 使用 CAP_SYS_ADMIN 權限也可能進行攻擊，在這種情況下，不需要支持用戶命名空間和訪問 cgroup v1 的根層次結構。
除了突破隔離的容器外，該漏洞還允許由沒有“能力”的root用戶或任何具有CAP_DAC_OVERRIDE權限的用戶啟動的進程（攻擊需要訪問由擁有的/sys/fs/cgroup/*/release_agent文件root) 以獲取對系統所有“功能”的訪問權限。
除了容器之外，該漏洞還可能允許沒有功能的根主機進程或具有 CAP_DAC_OVERRIDE 功能的非根主機進程將權限升級為完整功能。 這可能允許攻擊者繞過某些服務使用的強化措施，這些服務會刪除功能以嘗試在發生危害時限制影響。
Unit 42 建議用戶升級到固定內核版本。 對於那些正在運行的容器，啟用 Seccomp 並確保啟用 AppArmor 或 SELinux。 Prisma Cloud 用戶可以參考“Prisma Cloud 保護”部分來查看 Prisma Cloud 提供的緩解措施。
請注意，當使用 Seccomp、AppArmor 或 SELinux 保護機制進行額外的容器隔離時，無法利用該漏洞，因為 Seccomp 會阻止 unshare() 系統調用，並且 AppArmor 和 SELinux 不允許以寫入模式掛載 cgroupfs。
最後，值得一提的是，它已在內核版本 5.16.12、5.15.26、5.10.97、5.4.177、4.19.229、4.14.266 和 4.9.301 中修復。 您可以在這些頁面上關注發行版中軟件包更新的發布： Debian, SUSE, Ubuntu, RHEL, Fedora, Gentoo的, Arch Linux.
終於 如果您有興趣了解更多信息，您可以在中查看詳細信息 以下鏈接。