Уязвимость CVE-2019-5736 в runc, позволяющая получить права root на хосте

[ElegantBoomerang]

Запись в /proc/self/exec? На это хватило прав? Какие права проброшены внутрь контейнера? Столько интересных вопросов, аж жаль, что перевод.

[mk2]

Через 6 дней можно будет взглянуть на эксплоит и понять точно. Или перевести статью, где это сделал кто-то еще)

[mk2]

Закрытый — возможно. Но и сам автор говорит, что они написали демонстрационный, и откроют его 18 февраля. А на него уже посмотреть всем можно будет.

[shurup]

Из NVD (ссылка есть в статье):

This occurs because of file-descriptor mishandling, related to /proc/self/exe.

В этом патче (к LXC; тоже есть ссылка в статье) — больше подробностей:

The attack can be made when attaching to a running container or when starting a
container running a specially crafted image. For example, when runC attaches
to a container the attacker can trick it into executing itself. This could be
done by replacing the target binary inside the container with a custom binary
pointing back at the runC binary itself. As an example, if the target binary
was /bin/bash, this could be replaced with an executable script specifying the
interpreter path #!/proc/self/exe (/proc/self/exec is a symbolic link created
by the kernel for every process which points to the binary that was executed
for that process). As such when /bin/bash is executed inside the container,
instead the target of /proc/self/exe will be executed — which will point to the
runc binary on the host. The attacker can then proceed to write to the target
of /proc/self/exe to try and overwrite the runC binary on the host. However in
general, this will not succeed as the kernel will not permit it to be
overwritten whilst runC is executing. To overcome this, the attacker can
instead open a file descriptor to /proc/self/exe using the O_PATH flag and then
proceed to reopen the binary as O_WRONLY through /proc/self/fd/ and try to
write to it in a busy loop from a separate process. Ultimately it will succeed
when the runC binary exits. After this the runC binary is compromised and can
be used to attack other containers or the host itself.

[ElegantBoomerang]

Спасибо! То есть:

1. Мы заставляем exec-нуться в себя runc, теперь он запущен внутри контейнера.
2. Процесс не потерял fd-шку на себя потому что лапки.
3. Изнутри контейнера мы через этот fd начинает писать в бинарник.
4. У нас получается?!

[ElegantBoomerang]

Для желающих, я почитал доки: да, получится, ещё как! :D Одновременно красивый хак, но и безолаберный: запуск привилегированного контейнера это практически root, вот ещё один пример в коллекцию.

[MMik]

Выдохнул. Очередной повод порадоваться включенному SELinux, и поблагодарить разработчиков.

Пакет docker, как и podman, защищён от её эксплуатации, поскольку запускает процессы контейнера как container_t.

OpenShift Online and Dedicated are not vulnerable to exploit due to the use of SELinux in enforcing mode.
Customers using SELinux in enforcing mode can observe exploitation attempts by looking at AVC events in the audit logs. E.g.
$ aureport -a
AVC Report
===============================================================
# date time comm subj syscall class permission obj result event
===============================================================
1. 11/02/19 00:00:00 script system_u:system_r:container_t:s0:c530,c886 2 file write system_u:object_r:container_runtime_exec_t:s0 denied 81359
…

[Wimbo]

Очень хороший и подробный разбор данной проблемы: www.twistlock.com/labs-blog/breaking-docker-via-runc-explaining-cve-2019-5736