Уязвимость CVE-2019-11253 в YAML-парсере Kubernetes приводит к DoS-атаке

В issues проекта Kubernetes обсуждается потенциально опасная уязвимость в парсере YAML-документов kubectl/API Server, которая может привести к разновидности DoS-атак под названием billion laughs.

Для уязвимости уже зарезервирован номер: CVE-2019-11253, — однако детали CVE всё ещё не опубликованы. Широкой общественности о проблеме стало известно в результате обсуждения «YAML-бомбы» для Kubernetes API на Stack Overflow.

В Kubernetes-объекте ConfigMap, определяемом форматом YAML, могут содержаться так называемые «отсылки» (references) к другим блокам (nodes) документа. Это специальная фича YAML, созданная для удобства: для возможности использовать идентичные фрагменты конфигураций и сокращения общего размера YAML-документов. Проблема сводится к тому, что references могут быть рекурсивными, в результате чего потребление CPU стремительно вырастает.

Обнаруженную уязвимость назвали «родственником» уже хорошо известной проблемы при парсинге формата XML, которую называют billion laughs (по той причине, что для её иллюстрации обычно используют множество строк, содержащих «lol») или же XML-бомбой.

Пример для воспроизведения CVE-2019-11253 в Kubernetes — создать такой манифест:

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 create -f <manifest>). После выполнения такой команды остаётся лишь мониторить за потреблением процессора с помощью top или других подобных утилит.

Для полного решения проблемы разработчики Kubernetes ожидают «фундаментального патча в библиотеке YAML».

Из наиболее очевидных общих рекомендаций для избежания последствий подобных уязвимостей — закрытие Kubernetes API для внешних пользователей и грамотная конфигурация RBAC-политик в кластере. Подробнее о них рассказывается, например, в этой свежей статье.

P.S.

Читайте также в нашем блоге:

Let's block ads! (Why?)