Сообщество Linux занято сейчас устранением недавно обнаруженной уязвимости, которая касается средства для запуска контейнеров runC, используемого Docker, CRI-O, containerd и Kubernetes.
Уязвимость, получившая идентификационный номер 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?
Уязвимость, получившая идентификационный номер 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?
Комментарии (13)
ky0
13.02.2019 11:47+1Уважаемые читатели! А вы уже защитили свои системы от уязвимости runC?
Нам пофигу, у нас немодный LXC.
vesper-bot
13.02.2019 12:40LXC тоже зацепило, в первой статье есть инфа, что LXC имеет схожую уязвимость.
sn00p
13.02.2019 13:10Работает только с предварительно криво слепленным специальным контейнером. Как и большинство уязвимостей в Linux, сводится к тому, что
"SSHD remote root expoit found. A Remote attacker who knows root password can gain root access unless it's explicitly disabled in SSHD configuration."
beduin01
До адептов Docker никак не может дойти, что Docker не повышает безопасность, а снижает ее.
Контейнеры Docker как минимум плохо поддаются аудиту, а как максимум способствуют тому, чтобы разработчики лепили корявый и непереносимый софт.
wtpltd
Docker, это не пробезопасность, хотя изоляция приложений и перекликается с безопасностью.
Про аудит не понял — есть Dockerfile, в котором абсолютно четко расписано как создается контейнер. Можно проверить, что хочется.
Кривой софт вообще никак не связан с контейнеризаций. Если софт кривой, он будет кривым, где его ни запускай.
DRVTiny
>в котором абсолютно четко расписано как создается контейнер
В котором чётко прописано, что следует использовать внешнюю библиотеку такую-то версии от 2013-го года при том, что на официальном сайте давно лежит от 02.2019-го сборка и между той, что была в 2013 и той, что есть в 2019-м — десяток багфиксов, и среди них N-е количество security fix'ов.
Конечно, и security bug'ов добавилось с тех пор (как, возможно, и производительности насыпали, и каких-нибудь кривых зависимостей убрали), но атакующий-то о невыявленных пока ещё багах вряд ли что-то знает, поэтому будет рад софту, в котором куча дыр, описанных в security-бюллетенях за прошедшие 5 с лишним лет.
А почему такую замшелую библиотеку разработчики пихают в докер-контейнер? А потому что с ней — всё работает! Вот работало оно в 2013-м году, и в 2019-м работает. И, собственно, я не ошибусь, если скажу, что именно ради подобного (описание можете сами подставить по смыслу фразы) разработчики используют docker-контейнеры чаще всего. Они им нужны для того, чтобы с одной стороны таскать с собой целый ворох чужих библиотек, а с другой стороны — не дай Бог не подстраиваться к целевой системе. А то вдруг там библиотека не 2013-го года и скомпилированная, например, не со столь заботливо подобранными флагами, сакральные знания о которых передаются из поколение в поколение?
Безусловно, докер-контейнеры — это не про безопасность, и даже не про упаковку зависимостей, покрывающихся мхом и плесенью. Но большинство разработчиков используют докер не по назначению, а именно в качестве этакого грязного дырявого мешка, в который плотно набиваются все нужные костыли, чтобы при переносе на другую систему чудесное приложение не рассыпалось от ужасного столкновения с объективной реальностью, существующей где-то за рамками тестовых сред и разработческих макбуков.
sn00p
Какие-то страшилки для детей рассказываете. Вот, к примеру, репка с кучей докерфайлов.
github.com/vimagick/dockerfiles. Хоть один там найдете такой, как вы описали? Нет, не найдете. Все из пакетов, все с апстрима.
Прибивают еще иногда питон, ноду, акей, но у них специфика такая. Их запакетировать полностью просто невозможно. Так это не проблема докера, разработчики это делают абсолютно на всех системах одинаково.
Из сорцов еще иногда ставят, но там тоже все понятно с флагами и ключами. В докерфайле никакой магии нет, будет сделано все, как написано. Хорошо написано — хорошо будет сделано. Если написано плохо, результат будет, ожидаемо, соответствующий.
Также в нормальных registry уже давно все имаджи сканируются Clair, например, ну и подписываются до кучи.
Ну и разве разработчики «замшелые библиотеки» только в докер пихают? Вам пора менять взгляды, докер и подобные сервисы в тренде, миллионы людей это используют. Проблемы есть, но плюсов ощутимо больше.
Объективности ради. В объективной реальности существуют огромные кучи отвратного софта, которые даже в докер никак не поместить, не залезет. Их даже большие компании пишут. И за килобаксы умудряются продавать. Там не то что на другую систему перенести, даже обновить без курса психотерапии не выйдет. Так и крутится, пованивая из-под капота чудесным. Без всякого докера.
ihost
У docker-а скорее другая проблема: он не подходит для низкоуровневых highload приложений, вроде сетевого ввода/вывода на основе poll mode-драйвера IGB UIO на сервере с несколькими 40-гигабитными карточками. По очевидным причинам IGB UIO или KNI на docker-ах не запустить, а иначе сложно выжать соответствующую производительность
А не-highload приложения, не столь критичные к ресурсам, можно запускать и на виртуалках, или что еще лучше — в serverless-облаке.
JekaMas
А highload, но не низкоуровневые?
TrueMaker
Я думаю тут подменено понятие HPC. Highload это одно и может иметь отношение к огромной системе которая обслуживает сотни миллионов запросов в секунду, будучи слегка нагруженной в расчёте на один хост. HPC подразумевает обработку максимально возможного количества данных нагружая все доступные вычислительные ресурсы в пределах одной ноды и это определённо не highload в терминах распределённых сервисов.