From 0ceaa79e43a2571b84364e7997da7ac9b29a7ad8 Mon Sep 17 00:00:00 2001 From: nnz1024 <0comffdiz@inbox.ru> Date: Sat, 21 Oct 2017 16:17:24 +0300 Subject: [PATCH] =?UTF-8?q?=D0=94=D0=BE=D0=B1=D0=B0=D0=B2=D0=BB=D0=B5?= =?UTF-8?q?=D0=BD=20=D0=BF=D0=B5=D1=80=D0=B5=D0=B2=D0=BE=D0=B4=20=D1=81?= =?UTF-8?q?=D1=82=D0=B0=D1=82=D1=8C=D0=B8=20"Avoiding=20CVE-2016-8655=20wi?= =?UTF-8?q?th=20systemd"?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- s4a.tex | 91 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 91 insertions(+) diff --git a/s4a.tex b/s4a.tex index 6c3e952..6234f8c 100644 --- a/s4a.tex +++ b/s4a.tex @@ -5171,6 +5171,97 @@ localectl, busctl, systemd-analyze, systemd-run).}. подробностями обращайтесь к документации (начать изучение темы можно со ссылок, приведенных в этой статье). +\sectiona{Защита от уязвимостей \texttt{AF\_PACKET} при помощи +systemd\sfnote{Эта и последующие статьи официально не входят в цикл <>, и поэтому не~имеют порядковых номеров. Однако они сходны +по тематике с остальными статьями цикла и несут довольно много полезной +информации, и поэтому их перевод все же присутствует в данном документе.}} + +Небольшая заметка о том, как ограничительные механизмы, встроенные в последние +версии systemd, позволяют защитить ваши службы от эксплуатации +уязвимости \href{http://seclists.org/oss-sec/2016/q4/607}{CVE-2016-8655}% +\footnote{Прим. перев.: Решение перевести эту заметку связано с появлением +информации о целом ряде уязвимостей, связанных с +AF_PACKET+. Помимо уже +упомянутой автором CVE-2016-8655, это +\href{https://googleprojectzero.blogspot.com/2017/05/exploiting-linux-kernel-via-packet.html}% +{CVE-2017-7308}, +\href{http://seclists.org/oss-sec/2017/q3/279}{CVE-2017-10001111}, +\href{http://seclists.org/oss-sec/2017/q3/476}{CVE-2017-14497}, и +\href{http://seclists.org/fulldisclosure/2017/Oct/44}{еще одна}, на момент +написания этих строк не~имеющая идентификатора CVE. Все они имеют схожую природу +(повышение привилегий до root путем манипуляций с сокетами +AF_PACKET+) +и успешно блокируются описанным в статье методом. Соответственно, был изменен и +заголовок статьи (в оригинале речь шла только о CVE-2016-8655).}. + +Начиная с версии 211, в systemd добавлена поддержка новой директивы +для service-файлов~--- +\hreftt{https://www.freedesktop.org/software/systemd/man/systemd.exec.html\#RestrictAddressFamilies=}% +{RestrictAddressFamilies=}, которая отбирает у службы возможность создавать +сокеты определенного типа\footnote{Прим. перев.: Под <<типом сокета>> здесь +подразумевается address family. Не~вполне корректно, зато кратко.}. Достаточно +добавить в секцию +[Service]+ юнит-файла вашей службы строчку ++RestrictAddressFamilies=~AF_PACKET+, и служба утратит возможность создавать +сокеты типа +AF_PACKET+, в результате чего эксплуатация соответствующих +уязвимостей будет исключена. Приведенный пример демонстрирует режим <<черного +списка>>, когда указываются \emph{запрещенные} типы сокетов. Однако, более +безопасным подходом является <<белый список>> \emph{разрешенных} типов. В +отличие от черного, белый список указывается без символа +~+. Простой пример: +\begin{Verbatim} +... +[Service] +ExecStart=/usr/bin/mydaemon +RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX +... +\end{Verbatim} +Служба, настроенная таким образом, может использовать только сокеты типа ++AF_INET+, +AF_INET6+ и +AF_UNIX+, что должно быть достаточно для большинства +системных демонов (+AF_INET+~--- низкоуровневое название для IPv4, ++AF_INET6+~--- для IPv6, а +AF_UNIX+ соответствует локальным UNIX-сокетам). + +\href{https://github.com/systemd/systemd/blob/8e458bfe4e2aa36c939db62561b2a59206d78577/NEWS#L45}% +{Начиная с systemd 232}, мы добавили директивы +RestrictAddressFamilies=+ в +юнит-файлы всех служб, входящих в состав systemd, указав минимально +необходимый набор типов сокетов для каждой службы. + +С выходом systemd 233 мы +\href{https://github.com/systemd/systemd/pull/4536}{добавили} еще один метод +блокировки подобных уязвимостей. Директива +\hreftt{https://www.freedesktop.org/software/systemd/man/systemd.exec.html\#RestrictNamespaces=}% +{RestrictNamespaces=} позволяет ограничить перечень пространств имен +(namespaces), которые может использовать служба\footnote{Прим. перев.: +Пространства имен~--- специфичная для ядра Linux технология контейнерной +изоляции, позволяющая группе процессов иметь свой собственный сетевой стек +(network namespace), иерархию монтирования (mount namespace, также использовался +термин filesystem namespace), иерархию контрольных групп (cgroup namespace), +очереди сообщений POSIX и интерфейсы SysV IPC (IPC namespace), имя хоста (UTS +namespace), независимые списки индентификаторов процессов (PID namespace) и +пользователей/групп (user namespace). Лежат в основе систем контейнерной +изоляции, таких как LXC и Docker. Также широко используются в systemd для +обеспечения безопасности~--- см. главы \ref{sec:chroots} и +\ref{sec:security}.}. В частности, +RestrictNamespaces=yes+ полностью отключает +доступ к пространствам имен. Перечисление, например ++RestrictNamespaces=net ipc+, позволяет задать список разрешенных к +использованию пространств имен (в нашем случае это пространства имен для сети и +IPC)\footnote{Прим. перев.: Как и в предыдущем случае, можно поменять белый +список на черный, добавив перед ним символ +~+.}. Учитывая, что механизм +пространства имен пользователей (user namespace) уже давно является перманентным +источником опасных уязвимостей\footnote{Прим. перев.: В частности, для создания +сокетов +AF_PACKET+ требуется наличие полномочий +CAP_NET_RAW+ (или прав рута), +отсутствующих у большинства программ. Однако, если система разрешает +непривилигерованным процессам создавать новое пространство имен +пользователей (+sysctl kernel.unprivileged_userns_clone=1+), то злоумышленник +может создать новое user namespace, в котором его процесс будет иметь +полномочия рута и, соответственно, сможет создать новое сетевое пространство +имен, и в нем сокет типа +AF_PACKET+, с помощью которого он попытается получить +полномочия рута уже в основной системе.}, возможно, будет правильным +заблокировать использование пространств имен для тех служб, которым они +не~требуются (а таких служб большинство). + +Хочется надеяться, что в будущем сопровождающие дистрибутивов и апстримные +разработчики программ будут сами добавлять соответствующие ограничительные +директивы в поставляемые по умолчанию юнит-файлы, так как эти люди лучше знают, +какие именно привилегии минимально необходимы для функционирования их демонов. + \appendix \section{FAQ (часто задаваемые вопросы)\sfnote{Перевод статьи