initstring/lxd_rootПовышение привилегий в Linux через LXD
У участников локальной группы lxd в Linux-системах есть множество способов повысить свои привилегии до root. Этот репозиторий содержит примеры полностью автоматизированных локальных root-эксплойтов. Подробное объяснение уязвимости и прохождение эксплойта доступно в моём блоге здесь.
Приведённые ниже эксплойты — это не побег из контейнера, а локальные root-эксплойты, которые используют контейнеры и нацелены на хостовую ОС. Для успешной эксплуатации требуется низкопривилегированный доступ к хостовому окружению.
Я считаю, что моя стратегия в версии 2 эксплойта уникальна и была достаточно интересной (по крайней мере для меня), чтобы написать подробное объяснение в блоге по ссылке выше.
lxd_rootv1.sh монтирует файловую систему хоста / в контейнер, где низкопривилегированный пользователь хоста имеет root-доступ. Этот root-доступ отображается обратно на хост, позволяя добавить текущего пользователя в файл /etc/sudoers. Этот метод уже эксплуатировался другими до меня.lxd_rootv2.py монтирует приватный UNIX-сокет systemd хоста в контейнер, а затем снова пробрасывает его на хост через прокси-устройства LXD. Эти прокси-устройства имеют root-привилегии и передают свои учётные данные при взаимодействии через сокет, а не учётные данные инициирующего низкопривилегированного пользователя. Это используется для создания временного сервиса systemd, который добавляет текущего пользователя в файл /etc/sudoers.Оба эксплойта требуют контейнер, поэтому сначала создайте его. Затем запустите эксплойт с хостовой ОС, передав имя контейнера первым аргументом.
# Эксплойт с помощью v1
$ bash lxd_rootv1.sh <имя контейнера>
# Эксплойт с помощью v2
$ python3 lxd_rootv2.py <имя контейнера>
До того как я столкнулся с этими проблемами, в официальной документации LXD не было ничего, что предупреждало бы пользователей об опасности группы lxd. Любой, кто следовал официальным инструкциям по настройке LXD, добавил бы свою учётную запись в эту группу перед развёртыванием своего первого контейнера. Я открыл баг в Canonical, чтобы выразить свои опасения — вы можете прочитать всю ветку обсуждения здесь. Команда LXD быстро внесла изменения в документацию, в которой теперь чётко указано, что эта группа должна предоставляться только тем, кому доверен root-доступ.
Как всегда, взаимодействие с ребятами из Canonical через их баг-трекер было очень приятным опытом. Я хотел бы поблагодарить их за время и за внимательное отношение к моим идеям. Я настоятельно рекомендую другим исследователям безопасности обращаться к ним напрямую таким же образом.
Я не первый, кто эксплуатирует LXD. Эта проблема поднималась в нескольких тикетах на GitHub, начиная с 2016 года:
Первая ссылка — это первый человек (simpoir), который выявил этот риск, насколько мне известно.
@reboare написал отличный блог об эксплуатации LXD тем же методом, что и мой эксплойт v1, задолго до меня:
Спасибо команде LXD за создание очень классного инструмента. Я сам использую LXD и он мне очень нравится. Я не считаю, что это критический недостаток, мешающий использовать LXD; просто очень важно понимать потенциальный риск при добавлении пользователей в группу lxd.
Официального исправления ни для одной из этих уязвимостей не существует. Любой, кто использует LXD, должен знать, что добавление пользователей в группу lxd по сути превращает их в root.
Если вы используете LXD на хосте с одним пользователем, например на рабочей станции, возможно, лучше вообще не использовать группу lxd и запускать sudo, когда нужно обратиться к API.
Для общих сред, где несколько человек работают с контейнерами, возможно, лучше создать вложенные окружения. Каждый отдельный пользователь группы LXD сможет эксплуатировать своё собственное окружение, но затем ему придётся приложить больше усилий, чтобы выйти из этого контейнера и эксплуатировать другие.