Прим. перев.: Минувшей ночью Aleksa Sarai, старший инженер по контейнерам из SUSE Linux, сообщил в почтовой рассылке oss-sec о критической уязвимости в безопасности runc/LXC, которая позволяет злоумышленнику, имеющему доступ в изолированный контейнер, получить привилегии root на хостовой системе. Поскольку проблема выявлена в эталонной реализации исполняемой среды для контейнеров — runc, — она затрагивает многочисленные контейнерные системы включая Docker/Moby, Podman, cri-o (и собственно Kubernetes). Ниже представлены подробности в виде перевода сообщения инженера в почтовую рассылку.
Я являюсь одним из мейнтейнеров runc (нижележащей среды исполнения контейнеров, используемой в Docker, cri-o, containerd, Kubernetes и т.п.). Недавно стало известно об уязвимости, которую мы проверили и пропатчили.
Исследователи, обнаружившие уязвимость:
Кроме того, Aleksa Sarai (т.е. я) обнаружил, что более изощрённой версии этой уязвимости подвержен и LXC.
Уязвимость позволяет вредоносному контейнеру (с минимальным взаимодействием с пользователем) переписать хостовый бинарник runc и таким образом получить возможность исполнения кода с правами root на хосте. Степень взаимодействия с пользователем такова, что позволяет запускать любые команды (не важно, контролирует ли команду злоумышленник) с правами root в рамках контейнера в любом из этих контекстов:
Эта уязвимость не блокируется ни политикой AppArmor по умолчанию, ни политикой SELinux по умолчанию в Fedora* (потому что процессы контейнера выглядят как запущенные с
Вектор CVSSv3 (с рейтингом в 7.2) таков:
Проблеме назначен CVE-2019-5736.
* Проблема относится только к пакету
Прикладываю соответствующий патч, исправляющий проблему (
Обратите внимание, что патч, который я push'нул в master-ветку runc, является модифицированной версии этого патча, хоть они и идентичны функционально (если вы ещё не пропатчили свои файлы приложенным патчем, мы рекомендуем использовать upstream-версию).
Некоторые вендоры запросили код эксплоита, чтобы убедиться, что патчи решили проблему. Поскольку проблема очень серьёзна (особенно для вендоров публичных облаков), мы решили предоставить такой код. Эксплоит написан мною, является более общим, чем оригинальный код, предоставленный исследователями, и работает для LXC (не требует сильных модификаций для возможности применить для других уязвимых исполняемых сред). Подробности о том, как использовать код эксплоита, предоставлены в
В соответствии с правилами OpenWall, код эксплоита будет публично обнародован через 7 дней после CRD (т.е. 18 февраля 2019 года). Если у вас есть исполняемая среда для контейнеров, пожалуйста, предварительно убедитесь, что она не подвержена этой уязвимости.
Следует отметить, что в процессе дальнейшего расследования проблемы я обнаружил, что у LXC есть схожая уязвимость, и они уже push'нули схожий патч нашей совместной разработки. LXC немного сложнее эксплуатировать, однако сама проблема та же.
Обсуждение с представителями systemd-nspawn привело к выводу, что они уязвимости не подвержены (поскольку у них иной метод подключения к контейнеру для LXC и runc).
Со мной также связались представители Apache Mesos, сообщившие, что и они подвержены уязвимости (думаю, что они попросту использовали код эксплоита, который будет опубликован). Очень похоже, что большинство исполняемых сред для контейнеров подвержены уязвимости, если они предварительно не предпринимали весьма необычных действий по смягчению её возможного воздействия.
Мы настроили рассылку анонсов для будущих уязвимостей в безопасности: процесс присоединения к ней описан здесь (он основан на почтовой рассылке Kubernetes security-announce). Пожалуйста, присоединяйтесь, если распространяете любые исполняемые среды для контейнеров, которые зависят от runc (или других проектов OCI).
Проблема CVE-2019-5736 в трекерах популярных Linux-дистрибутивов:
… и запись в блоге Kubernetes (обратите внимание на раздел «What Should I Do?»).
Я являюсь одним из мейнтейнеров runc (нижележащей среды исполнения контейнеров, используемой в Docker, cri-o, containerd, Kubernetes и т.п.). Недавно стало известно об уязвимости, которую мы проверили и пропатчили.
Исследователи, обнаружившие уязвимость:
- Adam Iwaniuk;
- Borys Popławski.
Кроме того, Aleksa Sarai (т.е. я) обнаружил, что более изощрённой версии этой уязвимости подвержен и LXC.
Краткий обзор
Уязвимость позволяет вредоносному контейнеру (с минимальным взаимодействием с пользователем) переписать хостовый бинарник runc и таким образом получить возможность исполнения кода с правами root на хосте. Степень взаимодействия с пользователем такова, что позволяет запускать любые команды (не важно, контролирует ли команду злоумышленник) с правами root в рамках контейнера в любом из этих контекстов:
- Создание нового контейнера из контролируемого злоумышленником образа;
- Подключение (
docker exec) к существующему контейнеру, к которому ранее у злоумышленника был доступ на запись.
Эта уязвимость не блокируется ни политикой AppArmor по умолчанию, ни политикой SELinux по умолчанию в Fedora* (потому что процессы контейнера выглядят как запущенные с
container_runtime_t). Однако она блокируется корректным использованием пользовательских пространств имён (где root хоста не map'ится в пользовательское пространство имён контейнера).Вектор CVSSv3 (с рейтингом в 7.2) таков:
AV:L/AC:H/PR:L/UI:R/S:C/C:N/I:H/A:HПроблеме назначен CVE-2019-5736.
* Проблема относится только к пакету
moby-engine в Fedora. Пакет docker, как и podman, защищён от её эксплуатации, поскольку запускает процессы контейнера как container_t.Патчи
Прикладываю соответствующий патч, исправляющий проблему (
0001-nsenter-clone-proc-self-exe-to-avoid-exposing-host-b.patch). Он основан на ветке HEAD, хотя код в libcontainer/nsenter/ меняется настолько редко, что патч скорее всего применим практически к любой старой версии кодовой базы runc, с какой вы имеете дело.Обратите внимание, что патч, который я push'нул в master-ветку runc, является модифицированной версии этого патча, хоть они и идентичны функционально (если вы ещё не пропатчили свои файлы приложенным патчем, мы рекомендуем использовать upstream-версию).
Второстепенность кода эксплоита
Некоторые вендоры запросили код эксплоита, чтобы убедиться, что патчи решили проблему. Поскольку проблема очень серьёзна (особенно для вендоров публичных облаков), мы решили предоставить такой код. Эксплоит написан мною, является более общим, чем оригинальный код, предоставленный исследователями, и работает для LXC (не требует сильных модификаций для возможности применить для других уязвимых исполняемых сред). Подробности о том, как использовать код эксплоита, предоставлены в
README.В соответствии с правилами OpenWall, код эксплоита будет публично обнародован через 7 дней после CRD (т.е. 18 февраля 2019 года). Если у вас есть исполняемая среда для контейнеров, пожалуйста, предварительно убедитесь, что она не подвержена этой уязвимости.
Влияние на другие проекты
Следует отметить, что в процессе дальнейшего расследования проблемы я обнаружил, что у LXC есть схожая уязвимость, и они уже push'нули схожий патч нашей совместной разработки. LXC немного сложнее эксплуатировать, однако сама проблема та же.
Обсуждение с представителями systemd-nspawn привело к выводу, что они уязвимости не подвержены (поскольку у них иной метод подключения к контейнеру для LXC и runc).
Со мной также связались представители Apache Mesos, сообщившие, что и они подвержены уязвимости (думаю, что они попросту использовали код эксплоита, который будет опубликован). Очень похоже, что большинство исполняемых сред для контейнеров подвержены уязвимости, если они предварительно не предпринимали весьма необычных действий по смягчению её возможного воздействия.
Другие новости
Мы настроили рассылку анонсов для будущих уязвимостей в безопасности: процесс присоединения к ней описан здесь (он основан на почтовой рассылке Kubernetes security-announce). Пожалуйста, присоединяйтесь, если распространяете любые исполняемые среды для контейнеров, которые зависят от runc (или других проектов OCI).
P.S. От переводчика
Проблема CVE-2019-5736 в трекерах популярных Linux-дистрибутивов:
… и запись в блоге Kubernetes (обратите внимание на раздел «What Should I Do?»).
