web-dev-qa-db-ja.com

セキュリティ:Yaml Bomb:ユーザーはconfigmapを送信してkube-apiを再起動できます

yaml-bomb.yamlファイルを作成:

apiVersion: v1
data:
  a: &a ["web","web","web","web","web","web","web","web","web"]
  b: &b [*a,*a,*a,*a,*a,*a,*a,*a,*a]
  c: &c [*b,*b,*b,*b,*b,*b,*b,*b,*b]
  d: &d [*c,*c,*c,*c,*c,*c,*c,*c,*c]
  e: &e [*d,*d,*d,*d,*d,*d,*d,*d,*d]
  f: &f [*e,*e,*e,*e,*e,*e,*e,*e,*e]
  g: &g [*f,*f,*f,*f,*f,*f,*f,*f,*f]
  h: &h [*g,*g,*g,*g,*g,*g,*g,*g,*g]
  i: &i [*h,*h,*h,*h,*h,*h,*h,*h,*h]
kind: ConfigMap
metadata:
  name: yaml-bomb
  namespace: default

コマンドkubectl apply -f yaml-bomb.yamlを使用して、ConfigMap作成リクエストをKubernetes APIに送信します。

kube-api CPU /メモリの使用率が非常に高く、後で再起動します。

このようなyaml爆弾を防ぐにはどうすればよいですか?

18
maxwell jiang

これは billion laughts attack であり、YAMLプロセッサでのみ修正できます。

Wikipediaがここで間違っていることに注意してください。

「Billion laughs」攻撃は、参照を含めることができるすべてのファイル形式、たとえばこのYAML爆弾に対して存在するはずです。

問題は、ファイル形式に参照が含まれていることではありません。それらを拡張するプロセッサです。これは、複数の場所から実際に参照されるノードにアンカーが使用されるというYAML仕様の精神に反しています。ロードされたデータでは、アンカーとエイリアスは、エイリアスがアンカーノードのコピーに展開されるのではなく、同じオブジェクトへの複数の参照になるはずです。

例として、コードスニペットを貼り付けるときの オンラインPyYAMLパーサーオンラインNimYAMLパーサー (完全な開示:私の作業)の動作を比較します。 PyYAMLはエイリアスの展開によるメモリ負荷のために応答しませんが、NimYAMLはエイリアスを展開しないため、迅速に応答します。

Kubernetesがこの問題に苦しんでいるのは驚くべきことです。 Goで記述されているため、参照を適切に処理できると思いました。これを修正するには、彼らにバグを報告する必要があります。

14
flyx

@flyxが言うように、ここでの実際の修正はKubernetesで使用されるYAML解析ライブラリにあると思いますが、考えられるいくつかの緩和策があります。

興味深いことに、これをローカルマシンのKubernetesクラスターで実行すると、CPUスパイクがサーバー側ではなくクライアント側(kubectlプロセスがCPUをチャーンしている)であることがわかりました。

問題がサーバー側の場合、可能な軽減策はRBACを使用してConfigMap作成へのアクセスを最小限に抑え、場合によっては [〜#〜] opa [〜#〜] のようなアドミッションコントローラーを使用して確認することです。クラスターに適用される前にマニフェスト。

これはおそらく Kubernetesセキュリティ脆弱性対応チーム で提起され、適切な修正を実装できるようにする必要があります。

[〜#〜] edit [〜#〜]-問題が発生する場所は、使用されているクラスターのバージョンにある可能性があります。サーバー側の適用は、1.16でベータ版にアップグレードされました(デフォルトで有効になっている必要があります)。したがって、1.16クラスターでは、おそらくクライアントサイドではなくサーバーサイドにヒットします。

[〜#〜] edit [〜#〜]-1.16クラスターをセットアップしますが、kubectlでクライアント側としてCPU使用率を表示します...

[〜#〜] edit [〜#〜]-この問題を報告しました here も、 DoSは、curlの代わりにkubectlを使用してサーバー側で実現できます。

最終EDIT-これはCVE(CVE-2019-11253)を割り当てられ、Kubernetes 1.13+で修正されています。修正は、基盤となるYAML解析ライブラリ here にも適用されているため、他のGoプログラムは、最新バージョンを使用している限り問題ありません。


6
Rory McCune

さまざまな言語のYAMLパーサーの脆弱性を調査するTrustCom19論文があり、ほとんどのパーサーにはいくつかの問題があることが判明したため、これは一般的であり、この分野には最近のCVEがいくつかあります(論文の詳細:Laughter in the Wild:A Study into DoS) YAMLライブラリの脆弱性、TrustCom19。プレプリント: https://www.researchgate.net/publication/333505459_Laughter_in_the_Wild_A_Study_into_DoS_Vulnerabilities_in_YAML_Libraries

1
jens