Сообщество Linux занято сейчас устранением недавно обнаруженной уязвимости, которая касается средства для запуска контейнеров runC, используемого Docker, CRI-O, containerd и Kubernetes.
![image](https://habrastorage.org/r/w1560/getpro/habr/post_images/5ec/ea7/7c5/5ecea77c5d6a6b82c183ed7be167eeba.png)
Уязвимость, получившая идентификационный номер CVE-2019-5736, даёт заражённому контейнеру возможность перезаписать исполняемый файл runC на хосте и получить к нему root-доступ. Это позволяет такому контейнеру получить контроль над хостом и даёт атакующему возможность выполнять любые команды.
Алекса Сараи, инженер из SUSE, занимающийся поддержкой runC, опубликовал сообщение на Openwall, в котором говорится, что эта уязвимость, весьма вероятно, затрагивает большинство средств для работы с контейнерами. Кроме того, он отмечает, что уязвимость можно заблокировать благодаря правильной реализации пользовательских пространств имён, где не осуществляется мэппинг root-пользователя хоста в пользовательское пространство имён контейнера.
Некоторые компании сочли эту уязвимость важной, присвоив ей соответствующий рейтинг. Сараи говорит о том, что, в соответствии со спецификацией CVSSv3, ей присвоена оценка 7.2 из 10.
Уже разработан патч для устранения этой уязвимости, который доступен всем, кто пользуется runC. Множество разработчиков ПО и провайдеров облачных услуг предприняли меры по установке этого патча.
Надо отметить, что средство runC появилось благодаря усилиям компании Docker. Оно представляет собой OCI-совместимый интерфейс командной строки для запуска контейнеров.
Хотя уязвимость, о которой идёт речь, не относится исключительно к экосистеме Kubernetes, она, можно сказать, продолжает традиции критической уязвимости, обнаруженной ранее в этом году в данной платформе для оркестрации контейнеров. Та уязвимость повлияла на все системы, использующие Kubernetes, она даёт злоумышленникам полные административные привилегии на любом вычислительном узле, запущенном в кластере Kubernetes.
Для устранений той уязвимости был быстро разработан патч, но большинство специалистов тогда отметили, что они ожидают обнаружения и других уязвимостей Kubernetes.
Рани Оснат, вице-президент подразделения маркетинга в Aqua Security, говорит, что уязвимости ПО будут существовать всегда. То, что была обнаружена некая уязвимость — вполне ожидаемо. Он полагает, что будут найдены и другие уязвимости, так как они — это то, чего можно ожидать от любого программного обеспечения.
Компания Lacework, занимающаяся безопасностью облачных решений, обнаружила в прошлом году в интернете более 21000 открытых систем оркестрации контейнеров и API, которые могли бы стать мишенями для злоумышленников. Среди этих систем были кластеры Kubernetes, Docker Swarm, Mesos Marathon, Red Hat OpenShift и другие.
Кроме того, разработчикам ядра Linux не дают скучать и аппаратные уязвимости, такие, как Spectrum, Meltdown и Foreshadow. Член Linux Foundation Грег Кроа-Хартман, выступая в прошлом году на мероприятии Open Source Summit в Ванкувере, сказал, что в будущем найдутся и другие подобные уязвимости.
Уважаемые читатели! А вы уже защитили свои системы от уязвимости runC?
![image](https://habrastorage.org/getpro/habr/post_images/5ec/ea7/7c5/5ecea77c5d6a6b82c183ed7be167eeba.png)
Уязвимость, получившая идентификационный номер CVE-2019-5736, даёт заражённому контейнеру возможность перезаписать исполняемый файл runC на хосте и получить к нему root-доступ. Это позволяет такому контейнеру получить контроль над хостом и даёт атакующему возможность выполнять любые команды.
Алекса Сараи, инженер из SUSE, занимающийся поддержкой runC, опубликовал сообщение на Openwall, в котором говорится, что эта уязвимость, весьма вероятно, затрагивает большинство средств для работы с контейнерами. Кроме того, он отмечает, что уязвимость можно заблокировать благодаря правильной реализации пользовательских пространств имён, где не осуществляется мэппинг root-пользователя хоста в пользовательское пространство имён контейнера.
Некоторые компании сочли эту уязвимость важной, присвоив ей соответствующий рейтинг. Сараи говорит о том, что, в соответствии со спецификацией CVSSv3, ей присвоена оценка 7.2 из 10.
Уже разработан патч для устранения этой уязвимости, который доступен всем, кто пользуется runC. Множество разработчиков ПО и провайдеров облачных услуг предприняли меры по установке этого патча.
Надо отметить, что средство runC появилось благодаря усилиям компании Docker. Оно представляет собой OCI-совместимый интерфейс командной строки для запуска контейнеров.
О современных программных и аппаратных уязвимостях
Хотя уязвимость, о которой идёт речь, не относится исключительно к экосистеме Kubernetes, она, можно сказать, продолжает традиции критической уязвимости, обнаруженной ранее в этом году в данной платформе для оркестрации контейнеров. Та уязвимость повлияла на все системы, использующие Kubernetes, она даёт злоумышленникам полные административные привилегии на любом вычислительном узле, запущенном в кластере Kubernetes.
Для устранений той уязвимости был быстро разработан патч, но большинство специалистов тогда отметили, что они ожидают обнаружения и других уязвимостей Kubernetes.
Рани Оснат, вице-президент подразделения маркетинга в Aqua Security, говорит, что уязвимости ПО будут существовать всегда. То, что была обнаружена некая уязвимость — вполне ожидаемо. Он полагает, что будут найдены и другие уязвимости, так как они — это то, чего можно ожидать от любого программного обеспечения.
Компания Lacework, занимающаяся безопасностью облачных решений, обнаружила в прошлом году в интернете более 21000 открытых систем оркестрации контейнеров и API, которые могли бы стать мишенями для злоумышленников. Среди этих систем были кластеры Kubernetes, Docker Swarm, Mesos Marathon, Red Hat OpenShift и другие.
Кроме того, разработчикам ядра Linux не дают скучать и аппаратные уязвимости, такие, как Spectrum, Meltdown и Foreshadow. Член Linux Foundation Грег Кроа-Хартман, выступая в прошлом году на мероприятии Open Source Summit в Ванкувере, сказал, что в будущем найдутся и другие подобные уязвимости.
Уважаемые читатели! А вы уже защитили свои системы от уязвимости runC?