Две уязвимости с высоким уровнем угрозы затрагивают Rancher, платформу управления кластерами Kubernetes, и его составной компонент Steve. Первая даёт пользователю с правом создавать проекты доступ к чужому проекту в другом кластере, то есть повышение привилегий. Вторая связана с отсутствием проверки сертификата удалённого сервера и открывает путь к атаке "человек посередине". Затронуты ветки Rancher до 2.9.9, 2.10.5 и 2.11.1, а также ветки Steve до 0.5.13.
Две уязвимости в Rancher и Steve
Одно имя проекта на два кластера
Rancher хранит служебные объекты и секреты проекта в пространстве имён локального кластера. Имя этого пространства совпадает с именем самого проекта. Из-за этого пользователь, который может создавать проекты в одном кластере, способен дать новому проекту то же имя. Достаточно, чтобы так назывался чужой проект в другом кластере. Совпадение приводит к тому, что автор нового проекта получает доступ к чужому и повышает свои привилегии.
Уязвимость получила идентификатор CVE-2024-22031 и высокую оценку по классификации вендора. Вектор атаки сетевой, сложность высокая, требуются низкие привилегии. Практические последствия заметны сразу: доступ к чужому проекту означает работу с его ресурсами и секретами. Атакующий может читать и изменять то, что ему видеть не положено. Сложность эксплуатации высокая, зато других условий, кроме права создавать проекты, не нужно. Вендор относит проблему к классу повышения привилегий по матрице MITRE ATT&CK (база знаний о тактиках и техниках атакующих).
Исправление появилось в Rancher 2.9.9, 2.10.5 и 2.11.1. Теперь вместо имени проекта для пространства имён используется отдельное поле в описании проекта. Если поле не заполнено, например проект создан до обновления, Rancher продолжает работать по старой схеме. После установки изменить это поле нельзя. Ветка 2.8 осталась без исправления: вендор счёл правку слишком сложной и рискованной перед снятием версии с поддержки.
Steve не проверяет сертификат сервера
Вторая уязвимость, CVE-2023-32198, затронула Steve, компонент, через который интерфейс Rancher обращается к кластерам Kubernetes. По умолчанию Steve использовал небезопасный режим и не проверял сертификат удалённого сервера при установке соединения по TLS (протокол защищённой передачи данных). Это позволяло провести атаку "человек посередине" против сервисов, работающих через Steve.
Последствия видны на уровне интерфейса. Пользователь с правом создавать сервисы в локальном кластере Rancher может перехватить управление интерфейсом и показать свой собственный. Через подменённый интерфейс удобно собирать чувствительные данные, в том числе пароли других пользователей. Дополнительно открывается путь к межсайтовому скриптингу. Условие одно: параметр ui-offline-preferred должен быть вручную переведён в значение remote. По умолчанию Rancher ставит dynamic, и тогда описанный сценарий не работает.
Исправленные версии и обходные меры
Steve закрыт в версиях 0.2.1, 0.3.3, 0.4.4 и 0.5.13. Теперь компонент всегда проверяет сертификат сервера, опираясь на стандартные настройки TLS в Go. Пользователям, которые пока не могут обновиться, вендор советует подключаться только к доверенным серверам.
С Rancher ситуация сложнее. Обновление до 2.9.9, 2.10.5 или 2.11.1 снимает проблему, если ветка это позволяет. Для 2.8 исправления нет, поэтому остаются обходные меры. Прежде всего нельзя допускать, чтобы проекты в разных кластерах носили одинаковые имена. Проверить текущее состояние помогает команда, которую выполняют в локальном кластере с правами администратора:
| 1 | kubectl get projects -A -o=custom-columns='NAME:metadata.name' | sort | uniq -c |
Она покажет все имена проектов и число совпадений. Если у какого-то имени больше одного вхождения, система затронута. Такие проекты придётся удалить и создать заново, чтобы исключить столкновение пространств имён. Оставлять один проект из пары неразумно: пользователь мог уже выдать себе доступ к чужому.
Обе уязвимости объединяет природа ошибки. В первом случае доверенным считается имя проекта, во втором - удалённый сервер. Обе закрыты в актуальных ветках, а ветка Rancher 2.8 остаётся уязвимой до конца жизненного цикла. Организациям, которые держат Rancher в продакшене, обновление лучше планировать заранее.
Ссылки
- https://github.com/rancher/rancher/security/advisories/GHSA-8h6m-wv39-239m
- https://github.com/rancher/steve/security/advisories/GHSA-95fc-g4gj-mqmx
