В опубликованных несколько часов назад выпусках ядра Linux 3.14.73, 4.4.14 и 4.6.3 устранена (http://seclists.org/oss-sec/2016/q2/599) критическая уязвимость (CVE-2016-4997 (https://security-tracker.debian.org/tracker/CVE-2016-4997)), позволяющая локальному пользователю повысить свои привилегии или выполнить код с правами ядра. Уязвимость пока не устранена в дистрибутивах, обновление в процессе подготовки: SUSE (https://bugzilla.novell.com/show_bug.cgi?id=CVE-2016-4997), Ubuntu (https://people.canonical.com/~ubuntu-security/cve/2016/CVE-2...), Debian (https://security-tracker.debian.org/tracker/CVE-2016-4997), RHEL (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2016-4997).
Уязвимость присутствует в подсистеме netfilter и связана с недоработкой в обработчике setsockopt IPT_SO_SET_REPLACE. Проблема проявляется только при использовании пространств имён для изоляции сети и идентификаторов пользователей (user namespaces и network namespaces, сборка ядра с CONFIG_USER_NS=y и CONFIG_NET_NS=y). Так как user namespaces по умолчанию отключены в большинстве дистрибутивов, уязвимость представляет опасность в основном для систем, использующих изолированные контейнеры.В обычных условиях вызов compat_setsockopt() может выполнить только пользователь root, но в ядрах с поддержкой пространств имён для сети и идентификаторов пользователей данное ограничение снимается и функциональность доступна для непривилегированного пользователя, работающего внутри контейнера (т.е. пользователь из контейнера может обойти изоляцию, выполнив код на уровня ядра). Детальное описание метода эксплуатации планируется обнародовать на следующей неделе.
Примечательно, что в списке изменений (https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.6.3) к новым выпускам факт исправления уязвимости никак не отмечен. Более того, исправления были предложены (http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...) ещё для ветки 4.6-rc2 в апреле, без акцентирования внимания на наличие уязвимости, а начальный патч (http://marc.info/?l=netfilter-devel&m=145842428504125&w=2) был подготовлен (https://bugs.chromium.org/p/project-zero/issues/detail?id=758) компанией Google, отправлен разработчикам ядра и использован в Chrome OS в начале марта.URL: http://seclists.org/oss-sec/2016/q2/599
Новость: http://www.opennet.me/opennews/art.shtml?num=44669
> т.е. пользователь из контейнера может обойти изоляцию, выполнив код на уровня ядраНастолько эпично... А Selinux изолирует подобное?
Любителей отключать selinux у нас столько, что даже если он и изолирует, это мало кому поможет ))
Безопасность != удобство.
Вы так свято верите, что NSA SELinux защищает вас? Подскажу, что ключевое слово в нём "NSA".
Ключевое слово: _HUGE_ Performance impact
> Вы так свято верите, что NSA SELinux защищает вас? Подскажу, что ключевое
> слово в нём "NSA".Ты так говоришь, как будто NSA напихает бэкдоров в открытый код. А потом они сами не будут случайно бегать в мыле, когда всякие русские, китайские и исламские хакеры зайдут к ним в гости? Это было бы недальновидно, они тоньше работают. Всучили в SSL пробэкдоренный вариант эллиптических кривых и рады поуши. Тут правда некстати всякие Бернштейны подвернулись, а всякие непатриотичные гуглы даже в ssl библиотеки запихивают. Был бы гугл майкрософтом, а америка россией - кушали бы бы NIST P256 curve до скончания веков.
Святая простота! Гугел настолько плотно работает со спецслужбами ... что ты так даже с девушкой своей не сможешь :-)
> Святая простота! Гугел настолько плотно работает со спецслужбами ... что ты так
> даже с девушкой своей не сможешь :-)Так они поди сливают по запросу с своих серверов, тем более что бизнес-аналитики у них столько что они тебе про тебя расскажут больше чем ты знаешь о себе сам. А вот неконтролируемо лазить по своей инфраструктуре ни одна уважающая себя компания или служба не позволит. Хотя-бы потому что в конце концов этот бэкдор кто-нибудь найдет и получится как с комодохакером и дигинотаром. Те правда были совсем глупые и использовали активную директорию, так что после взлома аккаунта админа им оставалось только сушить весла.
>> т.е. пользователь из контейнера может обойти изоляцию, выполнив код на уровня ядра
> Настолько эпично... А Selinux изолирует подобное?изолирует. так что только отключатели селинукса в опасности
> позволяющая локальному пользователюА кто такой локальный пользователь в GNU/Linux? Есть какая-то принципиальная разница между пользователями, взаимодействующими с системой через подключенные к этому же компьютеру напрямую монитор и клавиатуру и пользователем, зашедшим через SSH?
> Есть какая-то принципиальная разница между пользователями, взаимодействующими с системой через подключенные к этому же компьютеру напрямую монитор и клавиатуру и пользователем, зашедшим через SSH?Да
Локальным всегда считался пользователь, имеющий аккаунт в системе и доступ к выполнению произвольного кода под своим uid.
> Локальным всегда считался пользователь, имеющий аккаунт в системе и доступ к выполнению
> произвольного кода под своим uid.А системный, по вашему, не имеет ни того и ни другого?
Он точно также имеет учётную запись и также может выполнять код, разница лишь в том, что у него домашний каталог в /var/lib и оболочка не позволяющая ему авторизироваться, только получить полномочия от рута.
У локального пользователя пользовательская оболочка /bin/bash и установлен пароль. У системного /bin/false и нет пороля, что не позволяет ему авторизироваться в системе. А если вы изменили в vipw пользовательскую оболочку на /bin/bash и задали ему пароль, то вы системного превратили в локального, с тем отличием, что у него uid ниже 1000 и домашний каталого не в /home, а скоррее всего в /var/lib но это роли никакой не играет.
> пользователем, зашедшим через SSH...Я, конечно, не пробовал заходить системным пользователем без пароля по публичному ключу, но даже если это возможно, то залогинитmся по SSH, как и через что угодно с пользовательской оболочкой /bin/false не возможно.
А если /usr/bin/csh и /usr/sbin/nologin - это какие юзеры? Локальные, глобальные или VIP?
> А если /usr/bin/csh и /usr/sbin/nologin - это какие юзеры? Локальные, глобальные или
> VIP?Поднятые некромантом или призванные демонологом.
Аххаххах! 5 баллов! :)
>Поднятые некромантом или призванные демонологом.Считается ли некромантологией случай, когда у демона хомяк в /var/empty а шеллом /dev/null ?
>>Поднятые некромантом или призванные демонологом.
> Считается ли некромантологией случай, когда у демона хомяк в /var/empty а шеллом
> /dev/null ?Это не никромантия, а какое-то костылестроение, или поттерство.
Системный хомяк должен быть у каждого системного пользователя в /var/lib/user_name или отведённом ему для этого месте в дистрибутиве. А для заглушки логина специально предназначено /bin/false, которое есть во всех дистрибутивах.
> А если /usr/bin/csh и /usr/sbin/nologin - это какие юзеры? Локальные, глобальные или
> VIP?Первый локальный, второй системный, при условии, что приведённые вами оболочки установлены в системе. У меня nologin установлена в /sbin/nologin.
А если шелло /usr/bin/dreamcatcher - это какой пользователь будет?
Локальный - это значит имеющий учетную запись в данной системе, могущий что-то запустить с правами юзера (нерута).Допустим запрос HTTP что-то выполняет на сервере, но произвольной команды такой запрос выполнить не может. А "локальный пользователь" - тот, кто может. Без разницы - с клавы или через SSH.
"Допустим запрос HTTP что-то выполняет на сервере, но произвольной команды такой запрос выполнить не может."
Счастливая и спокойная была бы жизнь, ни каких эксплуатаций веб дыр от имени процесса обрабатывающего подобные запросы ...
Ну так это уже и есть удалённая эксплуатация уязвимости, т.е. без входа пользователя в свой хомяк и шелл.
> Допустим запрос HTTP что-то выполняет на сервере, но произвольной команды такой запрос
> выполнить не может. А "локальный пользователь" - тот, кто может. Без
> разницы - с клавы или через SSH.А как запрос HTTP что-то выполняет на сервере, если у него юзера нет? А если в апаче/нгинхе/нужное вписать - дыра, позволяющая через HTTP выполнить произвольный код, запрос HTTP может выполнить команду или нет? Так имеет локального пользователя сервер HTTP или не имеет?
>Уязвимость пока не устранена в дистрибутивахв Void с утра ядро 4.6.3
фигово, что не написано ничего про 2.6.32 с шестилетними бекпортами, а у ональных бизнес-партнёров требуется подписка или access denied
> фигово, что не написано ничего про 2.6.32 с шестилетними бекпортами, а у
> ональных бизнес-партнёров требуется подписка или access denied1 О чём вы думали, когда вашим бизнес партнёрам RHEL без подписки предлагали вместо CentOS?
2 О чём думали ваши партнёры, когда соглашались на это?
3 Все ядра 2-ой версии устарели и не поддерживаются.
4 Red Hat всегда сам содержит все свои ядра, со своим блекджеком и патчами из актуальных ядер.
Пойду собирать вещи на Debian GNU/HURD. Уж ядро Линукс слишком костыльно и опасно. Возможно, и бэкдоры для спецслужб стоят годами.
> Пойду собирать вещи на Debian GNU/HURD. Уж ядро Линукс слишком костыльно и
> опасно. Возможно, и бэкдоры для спецслужб стоят годами.Лучше бы KDE под FreeBSD пропатчил, ей богу.
Да уж. Для HURD сегодня уже даже некому ядро поддерживать, не то что бекдвери туда внедрять.
>Возможно, и бэкдоры для спецслужб стоят годами.Так про один такой бекдор упомянула Анжелика выше.
о каких контейнерах вообще идет речь? lxc? вообще любых?[сообщение отредактировано модератором]
> мля, о каких контейнерах вообще идет речь? lxc? вообще любых?Контейнеры в Linux только одни, отличаются лишь инструменты и мелкие детали (доп. применение apparmor, selinux, seccomp и т.п.). Основа везде cgroups и namespaces. user namespaces последнее время почти во всех инструментах управления контейнерами поддерживается.
В linux никаких контейнеров нет, есть только набор отдельных ядерных фич (уже упомянутые namespaces, cgroups и многое другие вроде (v)tun/tap/eth...) из которых набирают фичи получая какие-то уровни изоляции. Некоторые конечные продукты в итоге называют контейнерами.
Демоны вылазят из контейнеров.
> Демоны вылазят из контейнеров.:)
Размуровались, демоны!