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

kubectl cp漏洞CVE-2019-1002101分析

Kube-proxy IPVS添加flag ipvs-strict-arp

近期bug fix數據分析

——本期更新內容 

 

 

kubectl cp漏洞

近期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版本均修復了該問題，具體修復方式可參考：

https://github.com/kubernetes/kubernetes/pull/75037

用戶能夠經過kubectl version --client命令查看本身使用的kubectl版本，並升級到1.11.9,1.12.7,1.13.5或1.14.0版本以修復該漏洞。

 

Kube-proxy IPVS添加flag ipvs-strict-arp

首先了解些背景知識。

kube-proxy的ipvs模式會將clusterIP/externalIP等綁定到節點上名爲kube-ipvs0的dummy設備，以確保節點上的ipvs規則能夠對訪問這些地址的流量做轉發。

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

echo 1 >/proc/sys/net/ipv4/conf/all/arp_ignore

echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

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

而本次的buf fix則是跟前面的改動有關，由於前面的改動雖然解決了loadbalancer的問題，可是又引入了其餘問題：有些CNI插件在主機和容器間的鏈接會用到ARP協議。所以咱們看到有些用戶升級到1.13後反饋下面的問題：

issue#72779：kube-proxy v1.13.0 and 1.13.1 brokes services with externalIPs

issue#71555：kube-proxy/IPVS: arpignore and arpannounce break some CNI plugins

而本bug fix也很簡單，就是爲kube-proxy加了一個啓動參數ipvs-strict-arp，默認爲0，即不改變節點上的ARP配置，若是須要改變，則設置該參數值爲1。

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

可是IPVS模式自己就有它獨特的優點，是iptables所沒有的，在這些優點的基礎上，必定要ipvs實現原來iptables實現的全部功能彷佛也不太合理。

 

近期bug fix數據分析

近期在咱們關注的1.13版本(1.13.5以後)沒有比較重要的bug fix發佈，爲數很少的幾條也都是集羣部署、第三方雲提供商、e2e測試相關，不須要太多關注。

前文提到的CVE-2019-1002101漏洞也是在1.13.5版本以前已經修復的，上次的bug fix已經覆蓋到，你們若是有興趣深刻研究的話能夠根據本文提供的pr連接學習。

最後咱們看下具體數據：

以下爲全部bug fix的彙總信息：

 

相關服務請訪問：https://support.huaweicloud.com/cce/index.html?utm_content=cce_helpcenter_2019