sofianehamlaoui/cve-2022-0492-checkerСкрипт для проверки, уязвима ли среда контейнера для побегов из контейнера через CVE-2022-0492.
Скрипт для проверки, уязвима ли среда контейнера к побегам из контейнера через CVE-2022-0492
4 февраля Linux объявил о CVE-2022-0492, новой уязвимости повышения привилегий в ядре.
CVE-2022-0492 отмечает логическую ошибку в группах управления (cgroups), функции Linux, являющейся фундаментальным строительным блоком контейнеров. Эта проблема выделяется как одно из самых простых повышений привилегий в Linux, обнаруженных в последнее время: ядро Linux ошибочно предоставило привилегированную операцию непривилегированным пользователям.
К счастью, стандартные меры безопасности в большинстве контейнерных сред достаточны для предотвращения побега. Контейнеры, работающие с AppArmor или SELinux, защищены. Тем не менее, если вы запускаете контейнеры без передовых методов безопасности или с дополнительными привилегиями, вы можете быть в зоне риска. В разделе «Затронут ли я?» перечислены уязвимые конфигурации контейнеров и даны указания, как проверить, уязвима ли среда контейнера.
Помимо контейнеров, уязвимость также может позволить процессам хоста с правами root, но без возможностей, или непривилегированным процессам хоста с возможностью CAP_DAC_OVERRIDE, повышать привилегии и получать все возможности. Это может позволить злоумышленникам обойти меру защиты, используемую некоторыми сервисами, которые ограничивают возможности в попытке уменьшить последствия в случае компрометации.
CVE-2022-0492 — это уже третья уязвимость ядра за последние месяцы, позволяющая вредоносным контейнерам совершать побег. Во всех трёх уязвимостях защита контейнеров с помощью Seccomp и либо AppArmor, либо SELinux была достаточной для предотвращения побега.
Монтирование cgroupfs требует возможности CAP_SYS_ADMIN в пространстве имён пользователя, которое содержит текущее пространство имён cgroup. По умолчанию контейнеры работают без CAP_SYS_ADMIN, и поэтому не могут смонтировать cgroupfs в исходном пространстве имён пользователя. Но с помощью системного вызова unshare() контейнеры могут создать новые пространства имён пользователя и cgroup, где они обладают возможностью CAP_SYS_ADMIN и могут смонтировать cgroupfs.
Fig. 1 - Контейнер создаёт новое пространство имён пользователя, где он будет иметь возможность CAP_SYS_ADMIN.
Не каждый контейнер может создать новое пространство имён пользователя — хостовая система должна поддерживать непривилегированные пространства имён пользователя. Это установлено по умолчанию, например, в последних версиях Ubuntu. Поскольку Seccomp блокирует системный вызов unshare(), только контейнеры, работающие без Seccomp, могут создать новое пространство имён пользователя. Контейнер, показанный на прилагаемом скриншоте, работает без Seccomp, AppArmor или SELinux.
Fig. 2 - Контейнер монтирует cgroup памяти в новых пространствах имён пользователя и cgroup.
На скриншоте выше контейнер успешно смонтировал cgroup памяти, но вы можете заметить, что файл release_agent не включён в смонтированный каталог!
Как упоминалось ранее, файл release_agent видим только в корневой cgroup. Одна из особенностей монтирования cgroupfs в пространстве имён cgroup заключается в том, что вы монтируете cgroup, к которой принадлежите, а не корневую cgroup.
Fig. 3 - Контейнер монтирует корневую RDMA cgroup в новых пространствах имён пользователя и cgroup.
Чтобы использовать уязвимость, нам нужно записать вредоносный release agent в файл release_agent. Как видно на Fig. 3 выше, этот файл принадлежит root, поэтому только процессы контейнера с правами root могут установить release agent. Fig. 4 показывает контейнер, устанавливающий release agent, а Fig. 5 показывает, что контейнер без root не может этого сделать.
Fig. 4 - Контейнер с root устанавливает release agent.
Fig. 5 - Контейнер без root не может установить release agent.
Заключительный шаг побега — вызов настроенного release_agent, который не требует никаких привилегий. Поскольку этот шаг всегда выполним, он не влияет на то, уязвима ли среда для CVE-2022-0492, и поэтому мы решили не включать его. Вы всё ещё можете увидеть, как выглядит полная эксплуатация, на скриншоте ниже.
Fig. 6 - Эксплуатация CVE-2022-0492 для побега из контейнера через пространство имён пользователя.
Вместо создания новых пространств имён пользователя и cgroup, возможна более простая эксплуатация, если контейнеру предоставлена возможность CAP_SYS_ADMIN. Контейнер, работающий с возможностью CAP_SYS_ADMIN, может монтировать cgroupfs без каких-либо ограничений. В качестве бонуса, большинство контейнеров сегодня работают без пространств имён cgroup, что означает, что смонтированная cgroup будет корневой cgroup с файлом release_agent.
Fig. 7 - В исходном пространстве имён cgroup монтирование cgroupfs всегда будет монтировать корневую cgroup, независимо от cgroup контейнера.
Даже с возможностью CAP_SYS_ADMIN, AppArmor и SELinux по-прежнему предотвращают монтирование, поэтому контейнеры, работающие с любым из них, не могут использовать CVE-2022-0492. Fig. 8 показывает контейнер, работающий без AppArmor и SELinux и с возможностью CAP_SYS_ADMIN, использующий CVE-2022-0492 для побега.
Fig. 8 - Эксплуатация CVE-2022-0492 для побега из контейнера через возможность CAP_SYS_ADMIN.
CVE-2022-0492 отмечает ещё одну уязвимость Linux, которая может быть использована для побега из контейнера. К счастью, среды, соблюдающие лучшие практики, защищены от этой уязвимости. Среды с ослабленными мерами безопасности, в которых размещаются ненадёжные или публично доступные контейнеры, как и следовало ожидать, находятся в зоне высокого риска. Как всегда, лучше всего обновить хосты до исправленной версии ядра.
Мы настоятельно рекомендуем запускать контейнеры с включёнными Seccomp и либо AppArmor, либо SELinux, чтобы защититься от этой уязвимости и от будущих zero-day уязвимостей в Linux. Многие уязвимости повышения привилегий в ядре Linux могут быть использованы для побега из контейнера только в том случае, если контейнеру разрешено создавать новое пространство имён пользователя, или, другими словами, когда контейнер работает без Seccomp.
© 2022 - Не Sofiane Hamlaooui - Делаем мир лучше 🌎
