【獨家】K8S漏洞報告 | CVE-2019-1002101解讀

近期kubernetes的kubectl cp命令發現安全問題(CVE-2019-1002101)， 該問題嚴重程度比較高，建議將kubectl升級到Kubernetes 1.11.9,1.12.7,1.13.5或1.14.0版本以解決此問題 。

kubectl cp命令允許使用者在容器和主機之間複製檔案，其基本原理是：

1. 在源地址將檔案打包。

2. 打包輸出內容作為stream流透過網路傳遞給目標地址。

3. 傳遞路徑包括：apiserver、kubelet、runtime

4. stream流在目的地址作為tar的輸入，解壓。

具體執行過程可以參考 kubernetes/pkg/kubectl/cmd/cp.go 檔案中的copyToPod和copyFromPod兩個函式。

在這個過程中，如果容器中的tar二進位制檔案是惡意的，它可以執行任何程式碼並輸出意外的惡意結果。當呼叫kubectl cp時，攻擊者可以使用它將檔案寫入使用者計算機上的任何路徑，僅受本地使用者的系統許可權限制。

目前社群在1.11-1.14版本均修復了該問題，具體修復方式可參考：

使用者可以透過kubectl version --client命令檢視自己使用的kubectl版本，並升級到1.11.9,1.12.7,1.13.5或1.14.0版本以修復該漏洞。

首先了解些背景知識。

kube-proxy的ipvs模式會將 clusterIP/externalIP 等繫結到節點上名為 kube-ipvs0 的dummy裝置，以確保節點上的ipvs規則可以對訪問這些地址的流量作轉發。

在1.13版本中，引入一個操作

以禁止IPVS模式下對 kube-ipvs0  dummy裝置上繫結的ip的ARP回覆，具體可參考pr #70530，該改動是為了修復ipvs模式下load banlancer型別service不能正常使用的問題(issue:#59976)。

而本次的buf fix則是跟前面的改動有關，因為前面的改動雖然解決了loadbalancer的問題，但是又引入了其他問題：有些CNI外掛在主機和容器間的連線會用到ARP協議。因此我們看到有些使用者升級到1.13後反饋下面的問題：

而本bug fix也很簡單，就是為kube-proxy加了一個啟動引數 ipvs-strict-arp ，預設為0，即不改變節點上的ARP配置，如果需要改變，則設定該引數值為1。

不得不說，這只是一個規避方案，無論是否使用該引數，kube-proxy ipvs模式下總有一部分功能受影響。

但是IPVS模式本身就有它獨特的優勢，是iptables所沒有的，在這些優勢的基礎上，一定要ipvs實現原來iptables實現的所有功能似乎也不太合理。

近期在我們關注的1.13版本(1.13.5之後)沒有比較重要的bug fix釋出，為數不多的幾條也都是叢集部署、第三方雲提供商、e2e測試相關，不需要太多關注。

前文提到的CVE-2019-1002101漏洞也是在1.13.5版本之前已經修復的，上次的bug fix已經覆蓋到，大家如果有興趣深入研究的話可以根據本文提供的pr連結學習。

最後我們看下具體資料：

如下為所有bug fix的彙總資訊：