Опубликованы (http://openwall.com/lists/oss-security/2017/03/29/2) сведения о 0-day уязвимости в ядре Linux (CVE-2017-7184 (https://security-tracker.debian.org/tracker/CVE-2017-7184)), которая была использована на соревновании Pwn2Own 2017 (https://www.opennet.me/opennews/art.shtml?num=46213) для демонстрации атаки на Ubuntu Linux, позволившей локальному пользователю выполнить код с правами root.
Уязвимость вызвана ошибкой во фреймворке преобразования сетевых пакетов XFRM (http://man7.org/linux/man-pages/man8/ip-xfrm.8.html), применяемом для реализации IPsec. В функции
xfrm_replay_verify_len(), вызываемой из xfrm_new_ae(), не выполнялась проверка заданных пользователем параметров replay_window, записываемый в буфер состояний. Манипулируя содержимым, связанным с данным параметром, атакующий может организовать запись и чтение данных в области памяти ядра за пределами выделенного буфера.
Несмотря на то, что эксплуатация был продемонстрирвоана в Ubuntu, проблема не специфична для данного дистрибутива и проявляется в любых других системах на базе ядра Linux. Как и в нескольких (https://www.opennet.me/opennews/art.shtml?num=45632) предыдущих (https://www.opennet.me/opennews/art.shtml?num=43659) root-уязвимостях в ядре, проблема может быть эксплуатирована только при включении пространств имён для идентификаторов пользователей (user namespaces).
Например, пакеты с ядром для Ubuntu и Fedora уязвимы по умолчанию, а ядро Debian может быть атаковано только после активации поддержки "user namespaces" (sysctl kernel.unprivileged_userns_clone=1). Из-за отсутствия поддержки "user namespaces" атака также затруднена на старые системы версиями ядра меньше 3.9.User namespaces используется для получения обычным пользователем прав CAP_NET_ADMIN, необходимых для настройки параметров XFRM. Так как создаваемое через user namespaces изолированное окружение и основная система обслуживаются одним ядром Linux, то эксплуатация уязвимости в ядре позволяет обойти ограничения "user namespaces" и получить привилегированный доступ к основной системе.
Для ядра Linux исправление доступно в виде (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...) патчей (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...). Обновления пакетов пока выпущены только для Ubuntu (https://www.ubuntu.com/usn/usn-3250-1/) и openSUSE, SUSE Linux Enerprise 12 (https://bugzilla.novell.com/show_bug.cgi?id=CVE-2017-7184). Проблема остаётся неисправленной в Fedora (https://bodhi.fedoraproject.org/updates/?releases=F25&type=s...), Debian (https://security-tracker.debian.org/tracker/CVE-2017-7184) и CentOS/RHEL 7 (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2017-7184). Уязвимость не затрагивает SLE 11, RHEL 5 и RHEL 6.
URL: http://openwall.com/lists/oss-security/2017/03/29/2
Новость: http://www.opennet.me/opennews/art.shtml?num=46281
> user namespacesУже в который раз.
вообще-то баг не в user namespaces, а в ipsec
Позволяющий руту получить права рута. Отличненько.
Полагаю, что не обязательно руту, а CAP_NET_ADMIN.
Позволяющая руту внутри _контейнера_, созданного непривилегированным пользователя, получить права рута на хосте.
Если "фича" увеличивает область атаки на порядок, не является ли она сама уязвимостью?
> Если "фича" увеличивает область атаки на порядок, не является ли она сама уязвимостью?Предлагаю удалить из ядра Linux сетевой стек. Во избежание.
Удалять не стоит. А вот давать кому попало CAP_NET_ADMIN — глупо.Но жадным долбоё**м хочется "чтоб Jango и Wordpress ставились из коробки без VPS". И все вдруг забывают, для чего нужен root, и почему давать кому-попало "полный но ограниченный" доступ к системе — плохая идея.
А зачем джанге и вордпрессу нет_админ? Они там интерфейсы конфигурируют? Или iptables настраивают?
А нахрен вообще нужны user namespaces? Мне тоже непонятно.
> А нахрен вообще нужны user namespaces? Мне тоже непонятно.как минимум хотя бы для того чтобы любая пользовательская программа могла бы *снять* с себя часть своих возможностей -- через выполнение chroot.. (как вариант: chroot в пустой каталог)
то есть чтобы можно было бы выполнить chroot -- без root, без SUID и без Capabilities
А вы хотели бы, чтобы и для контейнеров, и для основной системы было одно и то же пространство пользователей? Т. е. один универсальный root на всех?
>Если "фича" увеличивает область атаки на порядок, не является ли она сама уязвимостью?нет, не является
> Если "фича" увеличивает область атаки на порядок, не является ли она сама
> уязвимостью?контейнеризация, которой слепо доверяют в качестве единственной меры безопасности (а именно в этом случае бывае CAP_чтонибудь без реального рута) - да, безусловно, является ;-)
> контейнеризация, которой слепо доверяют в качестве единственной меры безопасности
> (а именно в этом случае бывае CAP_чтонибудь без реального рута) - да, безусловно,
> является ;-)
https://lists.altlinux.org/pipermail/sisyphus/2003-June/2431...
^^^^
В который раз? Оно только год,полтора как из EXPEREMENTAL вылезло
> Атака также затруднена на старые системы с версиями ядра меньше 3.9 из-за отсутствия в них поддержки "user namespaces".У рута затруднений не возникнет. Но вот только зачем ему это...
> У рута затруднений не возникнет. Но вот только зачем ему это...из user namespace вылезать, разумеется. Пробив днищ...э, простите, контейнер.
> ядро Debian и RHEL/CentOS 7 может быть атаковано только после явной активации поддержки "user namespaces" (sysctl kernel.unprivileged_userns_clone=1).
>...
> Проблема остаётся неисправленной в Fedora, Debian и CentOS/RHEL 7# lsb_release -a
LSB Version: :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch
Distributor ID: CentOS
Description: CentOS Linux release 7.3.1611 (Core)
Release: 7.3.1611
Codename: Core
# uname -a
Linux gw 3.10.0-514.10.2.el7.x86_64 #1 SMP Fri Mar 3 00:04:05 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
# sysctl -a|grep usernsНо
# lxc-checkconfig |grep -i user
User namespace: enabledТ.е. в системе напрочь отсутствует /proc/sys/kernel/unprivileged_userns_clone. Но LXC работает.
Зафиксили уже или я что-то не так понял?
unprivileged_userns_clone позволяет любому пользователю (nobody и т.п.) создать себе namespace и сделать там себя "ограниченным" рутом, тем самым получив возможность использовать сплоит.Если unprivileged_userns_clone отсутствует, уязвимость могут использовать только процессы, которые и так уже имеют рут внутри namespace. То есть тупо только для побега из namespace.
А, так вот о чём пару дней тому намёкивали.
Уязвимость в функции реализующей IPSec Anti-replay механизм, я правильно понял?
Неплохая очередная причина вынести сетку в отдельное адресное пространство?
Вот почему нужно собирать свои ядра, а не юзать дистрибные.
Отличный подход для Enterprise-а!
> Отличный подход для Enterprise-а!у энтерпрайса размером поболее подвальной лавчонки как раз обычно есть билдферма, лишние руки для ее обслуживания и, иногда, другие поводы пересобирать ведра.
Только чем это поможет в данном случае (учитывая что ему запросто может быть нужен и ipsec, и namespaces) - загадка.
Это даже не смешно. У вас представление об энтерпрайзе как сборище линукс-гиков?
Топикстартер забыл упомянуть, что в Debian это некатит, потому, что
>Unprivileged user namespaces are disabled in Debian, this only affectsnon-standard setups
> Топикстартер забыл упомянуть, что в Debian это некатит, потому, чтоВы невнимательно читали новость, там про это написано. "Например, пакеты с ядром для Ubuntu и Fedora уязвимы по умолчанию, а ядро Debian и RHEL/CentOS 7 может быть атаковано только после явной активации поддержки "user namespaces" (sysctl kernel.unprivileged_userns_clone=1)"