Kubernetes首個嚴重安全漏洞發現者，談發現過程及原理機制

北美時間11月26日，Kubernetes爆出嚴重安全漏洞，該漏洞由Rancher Labs聯合創始人及首席架構師Darren Shepherd發現。該漏洞CVE-2018-1002105（又名Kubernetes特權升級漏洞，https://github.com/kubernetes/ … 71411）被確認為嚴重性9.8分（滿分10分），惡意使用者可以使用Kubernetes API伺服器連線到後端伺服器以傳送任意請求，並通過API伺服器的TLS憑證進行身份驗證。這一安全漏洞的嚴重性更在於它可以遠端執行，攻擊並不複雜，不需要使用者互動或特殊許可權。
漏洞被發現並驗證後，Kubernetes快速響應並已經發布了修補版本v1.10.11、v1.11.5、v1.12.3和v1.13.0-rc.1。仍在使用Kubernetes v1.0.x至Kubernetes v1.9.x版本的使用者，被建議即刻停止並升級到修補版本。

本文由該漏洞的發現者、Rancher Labs聯合創始人及首席架構師Darren Shepherd所寫。他描述了自己發現這一漏洞的完整經過，剖析了問題的機制與原理，並分享了相應的解決方案以及他本人對Kubernetes、對開源社群的看法。

Amazon ALB的問題
這一切都始於2016年，當時Rancher Labs剛釋出了Rancher 1.6。2016年年中的時候，亞馬遜釋出了ALB，這是一個新的HTTP（7層）負載均衡器。ALB的設定比ELB容易得多，因此我們會建議使用者使用ALB。隨後很快，我們開始收到有關ALB後端設定失敗的報告，很多隨機請求只會得到401、403、404、503的報錯。然而，Rancher Labs的團隊無法重現這些錯誤，我們從社群成員那裡得到的日誌都沒有沒法成為參考。我們看到了HTTP請求和響應，但無法將其與程式碼相關聯。那個時候，我們只好認為是因為ALB釋出不久、產品本身可能存在些錯誤。除了ALB，我們之前從未遇到任何其他負載均衡器的問題。因此那時，我們只得最終告訴使用者不要使用ALB。
時間到了今年8月，又有Rancher社群成員向Rancher 2.1提交了同樣的問題（https://github.com/rancher/rancher/issues/14931）。仍和以前一樣，使用ALB會導致奇數401和403錯誤。這極大地引起了我的關注，因為Rancher 1.x和2.x之間沒有共同的程式碼，而且ALB現在應該也已經相當成熟了。反覆深入研究後，我發現問題與不處理非101響應和反向代理快取TCP連線有關。若您想要真正理解這個問題，您必須瞭解TCP連線重用、websockets如何使用TCP連線以及HTTP反向代理。
TCP連線重用
在一種非常天真的HTTP方法中，客戶端將開啟TCP socket，傳送HTTP請求，讀取HTTP響應，然後關閉TCP socket。很快你就會發現你花了太多時間開啟和關閉TCP連線。因此，HTTP協議具有內建的機制，以便客戶端可以跨請求重用TCP連線。
WebSockets
Websockets是雙向通訊，其工作方式與HTTP請求／響應流不同。為了使用websockets，客戶端首先會傳送HTTP升級請求，伺服器會以HTTP 101 Switch Protocols響應來響應這一請求。收到101之後，TCP連線將專用於websocket。在TCP連線的剩餘生命週期中，它是被認為是專用於該websocket連線的。這就意味著此TCP連線永遠不會被重新使用。
HTTP反向代理
HTTP反向代理（負載均衡器是一種反向代理）從客戶端接收請求，然後將它們傳送到不同的伺服器。對於標準HTTP請求，它只寫入請求，讀取響應，然後將響應傳送到客戶端。這種邏輯相當直接，而且Go也包含一個內建的反向代理：https://golang.org/pkg/net/htt … Proxy。
相比之下Websockets就複雜一點。對於websocket，你必須檢視請求，看到它是一個升級請求，然後傳送請求，讀取101響應，然後劫持TCP連線，然後開始來回複製位元組。對於反向代理，它不會在此之後檢視連線的內容，它只是建立一個“廢棄管道”。標準Go庫中不存在此邏輯，許多開源專案都編寫了程式碼來執行此操作。
錯誤所在
關於錯誤所在，太長不看版的解釋是，Kubernetes在啟動“廢棄管道”之前沒有檢查101響應。在程式碼的防禦中，不檢查101是挺常見的。（這也是我們上文所說的Rancher使用者會發現的Rancher 1.x和Rancher 2.x的問題的原因，即使Rancher 1.x和Rancher 2.x使用的是完成不同的程式碼。）錯誤的場景如下：

• 客戶端傳送websocket升級請求
• 反向代理向後端伺服器傳送升級請求
• 後端伺服器以404響應
• 反向代理啟動複製迴圈並將404寫入客戶端
• 客戶端看到404響應並將TCP連線新增到“空閒連線池”

在這種情況下，如果客戶端重新使用TCP連線，它將向TCP連線寫入請求，它將通過反向代理中的“廢棄管道”並將其傳送到前一個後端。通常這不會很糟糕，例如在負載均衡器的情況下，因為所有請求都會轉到同一組同類後端。但是，當反向代理是智慧的，並且是由其執行身份驗證、授權和路由（即Kubernetes所做的全部工作）時，就會出現此問題。
安全漏洞
因為101未被處理，所以客戶端最終使用TCP連線，該連線是對某些先前訪問的後端服務的“廢棄管道”。這將導致特權升級。問題是，Kubernetes將僅在反向代理中執行許多請求的授權。這意味著如果我執行一個授權失敗的websocket請求路由到一個kubelet，我可以保持與該kubelet的持久連線，然後執行我選擇的任何API命令，無論我是否被授權。例如，您可以在任何pod上執行exec並複製出secrets。因此，在這種情況下，已經授權的使用者基本上可以獲得對kubelet的完全API訪問（同樣的事情適用於通過kube-aggregation執行的服務）。
當您新增另一個反向代理時，會出現另一個問題。在這種情況下，您將HTTP負載均衡器放在Kubernetes API（非4層負載均衡器）之前。如果執行此操作，那個通過了身份驗證的、執行著“廢棄管道” 的TCP連線，將會被新增到一個任何使用者都可以訪問的空閒池中。那麼，使用者A建立了TCP連線，之後使用者B仍可重新使用該連線。這樣一來，未經過身份驗證的使用者就可以訪問您的Kubernetes叢集了。
此時你可能會感到恐慌，因為當然每個人都會在kube-apiserver前放置一個負載均衡器。唔……首先，您必須執行HTTP負載均衡器，而不是TCP負載均衡器。負載均衡器必須瞭解HTTP語義才能產生此問題。其次，幸運的是大多數反向代理並不關心101個回覆。這就是為什麼這個問題其實（在不少開源專案中）存在已久而未被發現的原因。大多數負載均衡器在看到升級請求而非101響應後不會重用TCP連線。所以，如果您會受到這一漏洞的影響，那麼您的Kubernetes設定應該已經不可靠了，您應該能看到隨機失敗或無法完成的請求。至少我知道ALB就是這樣工作的，所以你升級到了已修補該漏洞的Kubernetes版本之前，不要使用ALB。
簡而言之，Kubernetes的這一安全漏洞會允許具有正確許可權的任何經過身份驗證的使用者獲得更多許可權。如果您正在執行硬體多租戶叢集（內含不受信任的使用者），您確實應該擔心並且及時應對。如果您不擔心使用者主動互相攻擊（大多數多租戶叢集都是這樣），那麼不要驚慌，只需升級到已修補該漏洞的Kubernetes版本即可。最壞的情況，如果真的有未經身份驗證的使用者可以進入您的叢集，您的負載均衡器也有可能會阻止這種情況。只要不是將API暴露給世界，並且有在其上放置一些適當的ACL，也許你的叢集也還是安全的。
Rancher為Kubernetes保駕護航
對於使用Rancher Kubernetes平臺的使用者，你們更無須緊張。
對於把叢集部署在內網的使用者，完全不需要過於擔心此問題，因為外部無法直接入侵。
通過Rancher2.0或RKE部署的kubernetes叢集的使用者同樣不用過於擔心。因為通過Ranche2.0或RKE部署的叢集預設是禁止和匿名使用者訪問。針對通過pod exec/attach/portforward許可權提權問題，目前Kubernetes釋出通用的修復方法是通過升級到指定Kubernetes版本來修復，針對此Rancher也已經發布修復程式，具體修復方法請參考：https://forums.rancher.com/t/r … 12598
感謝開源

我深刻地感到，這次Kubernetes的這個安全漏洞的最初發現、修復和最終交付，證明了開源社群強大的生命力。我第一次發現這個問題，也是因為Rancher的非付費開源使用者給予我們的反饋。事實上，我們已經確認了這一問題並沒有影響Rancher 2.x的付費客戶，因為Rancher的HA架構恰好否定了ALB的行為，但我們還是去研究並解決了這個問題，因為我們太愛我們的開源使用者了。也正是在研究和修復這個問題的過程中，我發現了Kubernetes自身存在的安全隱患，並通過已建立的安全公開流程向Kubernetes社群反饋了該問題。

本文轉自DockOne-Kubernetes首個嚴重安全漏洞發現者，談發現過程及原理機制