摘要:北美時間月日,爆出嚴(yán)重安全漏洞,該漏洞由聯(lián)合創(chuàng)始人及首席架構(gòu)師發(fā)現(xiàn)。反復(fù)深入研究后,我發(fā)現(xiàn)問題與不處理非響應(yīng)和反向代理緩存連接有關(guān)。問題是,將僅在反向代理中執(zhí)行許多請求的授權(quán)。大多數(shù)負(fù)載均衡器在看到升級請求而非響應(yīng)后不會重用連接。
北美時間11月26日,Kubernetes爆出嚴(yán)重安全漏洞,該漏洞由Rancher Labs聯(lián)合創(chuàng)始人及首席架構(gòu)師Darren Shepherd發(fā)現(xiàn)。該漏洞CVE-2018-1002105(又名Kubernetes特權(quán)升級漏洞,https://github.com/kubernetes...)被確認(rèn)為嚴(yán)重性9.8分(滿分10分),惡意用戶可以使用Kubernetes API服務(wù)器連接到后端服務(wù)器以發(fā)送任意請求,并通過API服務(wù)器的TLS憑證進(jìn)行身份驗(yàn)證。這一安全漏洞的嚴(yán)重性更在于它可以遠(yuǎn)程執(zhí)行,攻擊并不復(fù)雜,不需要用戶交互或特殊權(quán)限。
漏洞被發(fā)現(xiàn)并驗(yàn)證后,Kubernetes快速響應(yīng)并已經(jīng)發(fā)布了修補(bǔ)版本v1.10.11、v1.11.5、v1.12.3和v1.13.0-rc.1。仍在使用Kubernetes v1.0.x至Kubernetes v1.9.x版本的用戶,被建議即刻停止并升級到修補(bǔ)版本。
本文由該漏洞的發(fā)現(xiàn)者、Rancher Labs聯(lián)合創(chuàng)始人及首席架構(gòu)師Darren Shepherd所寫。他描述了自己發(fā)現(xiàn)這一漏洞的完整經(jīng)過,剖析了問題的機(jī)制與原理,并分享了相應(yīng)的解決方案以及他本人對Kubernetes、對開源社區(qū)的看法。
Rancher Labs聯(lián)合創(chuàng)始人及首席架構(gòu)師 Darren Shepherd,同時也是Docker生態(tài)核心組織Docker治理委員會(DGAB)的全球僅有的四位個人頂級貢獻(xiàn)者之一。
Amazon ALB的問題
這一切都始于2016年,當(dāng)時Rancher Labs剛發(fā)布了Rancher 1.6。2016年年中的時候,亞馬遜發(fā)布了ALB,這是一個新的HTTP(7層)負(fù)載均衡器。ALB的設(shè)置比ELB容易得多,因此我們會建議用戶使用ALB。隨后很快,我們開始收到有關(guān)ALB后端設(shè)置失敗的報告,很多隨機(jī)請求只會得到401、403、404、503的報錯。然而,Rancher Labs的團(tuán)隊(duì)無法重現(xiàn)這些錯誤,我們從社區(qū)成員那里得到的日志都沒有沒法成為參考。我們看到了HTTP請求和響應(yīng),但無法將其與代碼相關(guān)聯(lián)。那個時候,我們只好認(rèn)為是因?yàn)锳LB發(fā)布不久、產(chǎn)品本身可能存在些錯誤。除了ALB,我們之前從未遇到任何其他負(fù)載均衡器的問題。因此那時,我們只得最終告訴用戶不要使用ALB。
時間到了今年8月,又有Rancher社區(qū)成員向Rancher 2.1提交了同樣的問題(https://github.com/rancher/ra...)。仍和以前一樣,使用ALB會導(dǎo)致奇數(shù)401和403錯誤。這極大地引起了我的關(guān)注,因?yàn)镽ancher 1.x和2.x之間沒有共同的代碼,而且ALB現(xiàn)在應(yīng)該也已經(jīng)相當(dāng)成熟了。反復(fù)深入研究后,我發(fā)現(xiàn)問題與不處理非101響應(yīng)和反向代理緩存TCP連接有關(guān)。若您想要真正理解這個問題,您必須了解TCP連接重用、websockets如何使用TCP連接以及HTTP反向代理。
TCP連接重用
在一種非常天真的HTTP方法中,客戶端將打開TCP socket,發(fā)送HTTP請求,讀取HTTP響應(yīng),然后關(guān)閉TCP socket。很快你就會發(fā)現(xiàn)你花了太多時間打開和關(guān)閉TCP連接。因此,HTTP協(xié)議具有內(nèi)置的機(jī)制,以便客戶端可以跨請求重用TCP連接。
WebSockets
Websockets是雙向通信,其工作方式與HTTP請求/響應(yīng)流不同。為了使用websockets,客戶端首先會發(fā)送HTTP升級請求,服務(wù)器會以HTTP 101 Switch Protocols響應(yīng)來響應(yīng)這一請求。收到101之后,TCP連接將專用于websocket。在TCP連接的剩余生命周期中,它是被認(rèn)為是專用于該websocket連接的。這就意味著此TCP連接永遠(yuǎn)不會被重新使用。
HTTP反向代理
HTTP反向代理(負(fù)載均衡器是一種反向代理)從客戶端接收請求,然后將它們發(fā)送到不同的服務(wù)器。對于標(biāo)準(zhǔn)HTTP請求,它只寫入請求,讀取響應(yīng),然后將響應(yīng)發(fā)送到客戶端。這種邏輯相當(dāng)直接,而且Go也包含一個內(nèi)置的反向代理:https://golang.org/pkg/net/ht...。
相比之下Websockets就復(fù)雜一點(diǎn)。對于websocket,你必須查看請求,看到它是一個升級請求,然后發(fā)送請求,讀取101響應(yīng),然后劫持TCP連接,然后開始來回復(fù)制字節(jié)。對于反向代理,它不會在此之后查看連接的內(nèi)容,它只是創(chuàng)建一個“廢棄管道”。標(biāo)準(zhǔn)Go庫中不存在此邏輯,許多開源項(xiàng)目都編寫了代碼來執(zhí)行此操作。
錯誤所在
關(guān)于錯誤所在,太長不看版的解釋是,Kubernetes在啟動“廢棄管道”之前沒有檢查101響應(yīng)。在代碼的防御中,不檢查101是挺常見的。(這也是我們上文所說的Rancher用戶會發(fā)現(xiàn)的Rancher 1.x和Rancher 2.x的問題的原因,即使Rancher 1.x和Rancher 2.x使用的是完成不同的代碼。)錯誤的場景如下:
客戶端發(fā)送websocket升級請求
反向代理向后端服務(wù)器發(fā)送升級請求
后端服務(wù)器以404響應(yīng)
反向代理啟動復(fù)制循環(huán)并將404寫入客戶端
客戶端看到404響應(yīng)并將TCP連接添加到“空閑連接池”
在這種情況下,如果客戶端重新使用TCP連接,它將向TCP連接寫入請求,它將通過反向代理中的“廢棄管道”并將其發(fā)送到前一個后端。通常這不會很糟糕,例如在負(fù)載均衡器的情況下,因?yàn)樗姓埱蠖紩D(zhuǎn)到同一組同類后端。但是,當(dāng)反向代理是智能的,并且是由其執(zhí)行身份驗(yàn)證、授權(quán)和路由(即Kubernetes所做的全部工作)時,就會出現(xiàn)此問題。
安全漏洞
因?yàn)?01未被處理,所以客戶端最終使用TCP連接,該連接是對某些先前訪問的后端服務(wù)的“廢棄管道”。這將導(dǎo)致特權(quán)升級。問題是,Kubernetes將僅在反向代理中執(zhí)行許多請求的授權(quán)。這意味著如果我執(zhí)行一個授權(quán)失敗的websocket請求路由到一個kubelet,我可以保持與該kubelet的持久連接,然后運(yùn)行我選擇的任何API命令,無論我是否被授權(quán)。例如,您可以在任何pod上運(yùn)行exec并復(fù)制出secrets。因此,在這種情況下,已經(jīng)授權(quán)的用戶基本上可以獲得對kubelet的完全API訪問(同樣的事情適用于通過kube-aggregation運(yùn)行的服務(wù))。
當(dāng)您添加另一個反向代理時,會出現(xiàn)另一個問題。在這種情況下,您將HTTP負(fù)載均衡器放在Kubernetes API(非4層負(fù)載均衡器)之前。如果執(zhí)行此操作,那個通過了身份驗(yàn)證的、運(yùn)行著“廢棄管道” 的TCP連接,將會被添加到一個任何用戶都可以訪問的空閑池中。那么,用戶A創(chuàng)建了TCP連接,之后用戶B仍可重新使用該連接。這樣一來,未經(jīng)過身份驗(yàn)證的用戶就可以訪問您的Kubernetes集群了。
此時你可能會感到恐慌,因?yàn)楫?dāng)然每個人都會在kube-apiserver前放置一個負(fù)載均衡器。唔……首先,您必須運(yùn)行HTTP負(fù)載均衡器,而不是TCP負(fù)載均衡器。負(fù)載均衡器必須了解HTTP語義才能產(chǎn)生此問題。其次,幸運(yùn)的是大多數(shù)反向代理并不關(guān)心101個回復(fù)。這就是為什么這個問題其實(shí)(在不少開源項(xiàng)目中)存在已久而未被發(fā)現(xiàn)的原因。大多數(shù)負(fù)載均衡器在看到升級請求而非101響應(yīng)后不會重用TCP連接。所以,如果您會受到這一漏洞的影響,那么您的Kubernetes設(shè)置應(yīng)該已經(jīng)不可靠了,您應(yīng)該能看到隨機(jī)失敗或無法完成的請求。至少我知道ALB就是這樣工作的,所以你升級到了已修補(bǔ)該漏洞的Kubernetes版本之前,不要使用ALB。
簡而言之,Kubernetes的這一安全漏洞會允許具有正確權(quán)限的任何經(jīng)過身份驗(yàn)證的用戶獲得更多權(quán)限。如果您正在運(yùn)行硬件多租戶集群(內(nèi)含不受信任的用戶),您確實(shí)應(yīng)該擔(dān)心并且及時應(yīng)對。如果您不擔(dān)心用戶主動互相攻擊(大多數(shù)多租戶集群都是這樣),那么不要驚慌,只需升級到已修補(bǔ)該漏洞的Kubernetes版本即可。最壞的情況,如果真的有未經(jīng)身份驗(yàn)證的用戶可以進(jìn)入您的集群,您的負(fù)載均衡器也有可能會阻止這種情況。只要不是將API暴露給世界,并且有在其上放置一些適當(dāng)?shù)腁CL,也許你的集群也還是安全的。
Rancher為Kubernetes保駕護(hù)航
對于使用Rancher Kubernetes平臺的用戶,你們更無須緊張。
對于把集群部署在內(nèi)網(wǎng)的用戶,完全不需要過于擔(dān)心此問題,因?yàn)橥獠繜o法直接入侵。
通過Rancher2.0或RKE部署的kubernetes集群的用戶同樣不用過于擔(dān)心。因?yàn)橥ㄟ^Ranche2.0或RKE部署的集群默認(rèn)是禁止和匿名用戶訪問。針對通過pod exec/attach/portforward權(quán)限提權(quán)問題,目前Kubernetes發(fā)布通用的修復(fù)方法是通過升級到指定Kubernetes版本來修復(fù),針對此Rancher也已經(jīng)發(fā)布修復(fù)程序,具體修復(fù)方法請參考:https://forums.rancher.com/t/...
感謝開源
我深刻地感到,這次Kubernetes的這個安全漏洞的最初發(fā)現(xiàn)、修復(fù)和最終交付,證明了開源社區(qū)強(qiáng)大的生命力。我第一次發(fā)現(xiàn)這個問題,也是因?yàn)镽ancher的非付費(fèi)開源用戶給予我們的反饋。事實(shí)上,我們已經(jīng)確認(rèn)了這一問題并沒有影響Rancher 2.x的付費(fèi)客戶,因?yàn)镽ancher的HA架構(gòu)恰好否定了ALB的行為,但我們還是去研究并解決了這個問題,因?yàn)槲覀兲珢畚覀兊拈_源用戶了。也正是在研究和修復(fù)這個問題的過程中,我發(fā)現(xiàn)了Kubernetes自身存在的安全隱患,并通過已建立的安全公開流程向Kubernetes社區(qū)反饋了該問題。
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://m.specialneedsforspecialkids.com/yun/32788.html
摘要:首爆嚴(yán)重安全漏洞,嚴(yán)重性分于昨晚爆出嚴(yán)重安全漏洞,該漏洞由聯(lián)合創(chuàng)始人及首席架構(gòu)師發(fā)現(xiàn)。其他功能更新對第三方設(shè)備監(jiān)控插件的支持該功能目前被引入為功能。拓?fù)涓兄碚{(diào)度該功能現(xiàn)成為狀態(tài)。 K8S首爆嚴(yán)重安全漏洞,嚴(yán)重性9.8分 Kubernetes于昨晚爆出嚴(yán)重安全漏洞,該漏洞由Rancher Labs聯(lián)合創(chuàng)始人及首席架構(gòu)師Darren Shepherd發(fā)現(xiàn)。該漏洞CVE-2018-1002...
摘要:今天,發(fā)布了一系列補(bǔ)丁版本,修復(fù)新近發(fā)現(xiàn)的兩個安全漏洞命令安全漏洞和端口映射插件漏洞。因?yàn)槎丝谟成洳寮乔度氲桨姹局械模挥猩壷列掳姹镜牟拍芙鉀Q此問題。現(xiàn)在修復(fù)之后,將端口映射插件的規(guī)則由最優(yōu)先變?yōu)楦郊樱瑒t可以讓流量優(yōu)先由規(guī)則處理。 今天,Kubernetes發(fā)布了一系列補(bǔ)丁版本,修復(fù)新近發(fā)現(xiàn)的兩個安全漏洞CVE-2019-1002101(kubectl cp命令安全漏洞)和CVE-...
摘要:本文將介紹通過強(qiáng)身份驗(yàn)證如何確保企業(yè)的集群免受外部攻擊。服務(wù)器雖然面向公開,但是受到證書身份驗(yàn)證的保護(hù)。年年底被爆出的首個嚴(yán)重安全漏洞,就是由聯(lián)合創(chuàng)始人及首席架構(gòu)師發(fā)現(xiàn)的。 毋庸置疑,K8s已經(jīng)成為云容器編排系統(tǒng)的標(biāo)準(zhǔn),但是,如果缺乏K8s環(huán)境相關(guān)的安全問題認(rèn)識的話,會致使各種組件暴露在網(wǎng)絡(luò)集群內(nèi)外的攻擊之下。本文將介紹通過強(qiáng)身份驗(yàn)證如何確保企業(yè)的K8s集群免受外部攻擊。 showIm...
摘要:爆出中等嚴(yán)重性安全漏洞拒絕服務(wù)漏洞。本文將進(jìn)行漏洞解讀和情景再現(xiàn),并分享漏洞修復(fù)方案,用戶來看應(yīng)對之策了漏洞美國當(dāng)?shù)貢r間年月日,社區(qū)發(fā)布了拒絕服務(wù)的漏洞,即有寫入權(quán)限的用戶在寫入資源時會導(dǎo)致過度消耗資源,此漏洞被評級為中等嚴(yán)重性。 Kubernetes爆出中等嚴(yán)重性安全漏洞——Kubernetes API Server拒絕服務(wù)漏洞CVE-2019-1002100。 本文將進(jìn)行漏洞解讀和...
摘要:年月阿里巴巴高級技術(shù)專家許真恩慕義發(fā)布了首個開源版本,作為的開源實(shí)現(xiàn)截止目前已經(jīng)更新到了的大版本,并且支持大規(guī)模生產(chǎn)版本。支持目前幾乎所有主流的微服務(wù)生態(tài)體系。 前言 6月份阿里開源的Nacos出了1.0.1版本,從去年7月份第一個release版本到現(xiàn)在一直在默默關(guān)注 官方的版本規(guī)劃為:Nacos從0.8.0開始支持生產(chǎn)可用,1.0版本可大規(guī)模生產(chǎn)可用,2.0版本接入k8s、Spri...
閱讀 833·2021-11-22 11:59
閱讀 3250·2021-11-17 09:33
閱讀 2320·2021-09-29 09:34
閱讀 1949·2021-09-22 15:25
閱讀 1967·2019-08-30 15:55
閱讀 1330·2019-08-30 15:55
閱讀 540·2019-08-30 15:53
閱讀 3353·2019-08-29 13:55