Исследователи безопасности из группы Zero (https://www.opennet.me/opennews/art.shtml?num=40210), созданной компанией Google для предотвращения атак, совершаемых с использованием ранее неизвестных уязвимостей, раскрыли (http://googleprojectzero.blogspot.ru/2016/06/exploiting-recu...) информацию о новой технике атак (CVE-2016-1583 (https://security-tracker.debian.org/tracker/CVE-2016-1583)) на ядро Linux. В качестве примера представлен эксплоит (https://bugs.chromium.org/p/project-zero/issues/detail?id=836), позволяющий локальному пользователю поднять свои привилегии в системе, в которой применяется шифрование домашних директорий при помощи eCryptfs.Метод позволяет через формирование рекурсивных вызовов в пространстве пользователя добиться переполнения стека ядра. Использующие стек файловые системы, такие как eCryptfs, имеют защиту от глубокой вложенности путей, но предложенный эксплоит обходит данную защиту. Атакующий может организовать цепочку рекурсивных отражений в память файла /proc/$pid/environ, при которой процесс 1 отражает в своё окружение файл /proc/2/environ, процесс 2 файл /proc/3/environ и т.д. Далее, если прочитать содержимое /proc/1/environ будет вызван обработчик pagefault для процесса 1, что приведёт к вызову pagefault для процесса 2 и т.д. по выстроенной цепочке до тех пор пока не переполнится стек ядра.
eCryptfs применяется для совершения атаки так как из-за применения шифрования не просто вызывается операция mmap, а дополнительно используется отдельный кэш страниц памяти и собственный обработчик mmap, который использует методы чтения и записи, предоставляемые низлежащей ФС, что позволяет использовать mmap для файлов, которые в обычных условиях не должны отражаться в память, например, для /proc/$pid/mem, /proc/$pid/memenviron и /proc/$pid/mem/cmdline.
В системах c suid-утилитой /sbin/mount.ecryptfs_private, например в Ubuntu, при активации шифрования для домашней директории, атака может быть совершена непривилегированным пользователям, которому предоставлена возможность создания разделов ecryptfs для своих файлов (так как /proc/$pid связан с принадлежащим пользователю процессом и директория принадлежит пользователю, ecryptfs допускает /proc/$pid в качестве источника монтирования).
Для защиты предлагается запретить любые вложенные операции с procfs, блокировать открытие файлов с f_op->mmap==NULL через ecryptfs, предоставить для ecryptfs отдельный кэш ядра, отделённый от кэша, применяемого при прямом отражении физической памяти, и вынести структуру thread_info в другое место. Соответствующие (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....) исправления (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....) уже приняты в состав ядра Linux, предложены (https://lkml.org/lkml/2016/6/15/1064) для включения и дополнительные методы защиты. Обновление ядра с устранением уязвимости уже выпущены для Ubuntu Linux, Debian (https://security-tracker.debian.org/tracker/DLA-516-1) и SUSE (https://bugzilla.novell.com/show_bug.cgi?id=CVE-2016-1583). Исправление для RHEL/CentOS 5/6 (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2016-1583) будет представлено в ближайшем обновлении (ветка 7 не подвержена проблеме).
URL: http://googleprojectzero.blogspot.ru/2016/06/exploiting-recu...
Новость: http://www.opennet.me/opennews/art.shtml?num=44634
>поднять свои привилегии в системе, в которой применяется шифрованиеЧем больше секьюрности, тем меньше секьюрности. Иронично...
есть мнение, что всё это fs-level-шифрование крайне ущербная штука, а для секюрности, надёжности и пр. надо использовать block level. по крайней мере, все мои опыты говорили именно об этом.
Опыты показали, что ты все свои фс без ключа расшифровал? Иди получать медаль и назначение в фсб.
А ты в ЦРУ. Ну хватит уже писать феерический бред.
Не я начал не я и хватать буду. У чела фс-левел шифрование несекьюрно, что тон неоднократно своимим опытами подтверждал. Пусть пруф выкатит или затнется.
Поддержу этого анонима.
у меня очень красиво эта самая ecryptfs рассыпалась и теряла файлы. раза три за полгода. после этого я использую только dm-crypt, с ним такой проблемы на том же железе не было ни разу.
Как-то неправильно вы его используете.
да используем нормально, ноут из саспенда не всегда просыпался, поэтому иногда нужен был hard reset. dm-crypt + ext4 переносил его нормально, а ext4 с ecryptfs поверх -- нет. кстати, с truecrypt + ntfs этой проблемы тоже нет.можешь экстраполировать эту ситуацию на прочие глюки с железом, с питанием, с ядром и пр. они иногда бывают. и ecryptfs с их последствиями справляется существенно хуже других альтернатив (что, собственно, не удивительно, если знать, как оно устроено).
> у меня очень красиво эта самая ecryptfs рассыпалась и теряла файлы.Дураки должны страдать.
А пользователи с рейтингом менее -11130 баллов должны подтираться вместе со всеми своими сообщениями.
> А пользователи с рейтингом менее -11130 баллов должны подтираться вместе со всеми
> своими сообщениями.На свой рейтинг посмотри ;)
Это рейтинг коллективного бессознательного, не считается.
Чем выше шифрование в стёке ФС тем лучше.
Для файла можно один раз посчитать хэш, для блоков придётся считать много хэшей.
Для файла нужен отдельный ключ/соль, для блоков - каждому отдельное.
Да чуть-ли не норма.
Самая хитрошифрованная система бессильна против пароля 123.
Хитрошифрованная такой пароль поставить не даст.
Уязвимость проявляется только в конкретном eCryptfs.
В Убунте, например, он устанавливается ТОЛЬКО в том случае, если шифруется домашний каталог. Кто-нибудь этим вообще пользуется?Просто напомню: никаких уязвимостей в TrueCrypt под Linux так и не всплыло...
Кто-нибудь этим вообще пользуется?Судя по интернет-форумам - пользуются. Тем более в инсталяторе есть конфигурилка.
Там же главный аргумент против блочного шифрования всего раздела - зачем шифровать bin, если там много предсказуемых данных?
У меня главный аргумент против шифрования чего бы то ни было другой.
Зачем шифровать то, что совершенно незачем шифровать?
Даже домашний раздел в основном занят информацией, не имеющей никакой ценности.
Для того, чтобы было труднее обнаружить то, что шифровать есть зачем.
Вы все еще прячете порно в Program Files?
Ну, вот лежит у меня на самом видном месте файлик с расширением .tc (а на флешке - еще и его копия). Да, у меня тут кое-что лично мне дорогое спрятано (нет, не порно, отвлекитесь уже). В чем я прокололся?
>В чем я прокололся?Дык! :)
>Program Files
Не-е, я хитрый. Я прячу Program Files в ~/.wine :)
Информация из домашнего каталога приобретает ценность не до утечки, а после, когда тебя начинают ею шантажировать или на её основании выносится приговор "пожизненно с полной конфискацией".
Например?
Проще зашифровать всё, чем на каждый чих думать "а не дописал ли я сюда то, чот надо зашифровать" и "не зименились ли обстоятельства так, что надо шифровать половину того, что сейчас в открытом виде лежит". Уж больно велики шансы забыть.
т.е. за encfs можно не переживать?
> т.е. за encfs можно не переживать?Полагаю, можно не переживать вообще. Условия для рвботы эксплойта дают не настолько большую потенциальную аудиторию, чтобы кто-то всерьез его использовал.
>On systems with the /sbin/mount.ecryptfs_private helper installed (e.g. Ubuntu if the "encrypt my home directory" checkbox is ticked during installation), this bug can be triggered by an unprivileged user.прикольно. попытка увеличения защиты приводит к уменьшению защиты
>>On systems with the /sbin/mount.ecryptfs_private helper installed (e.g. Ubuntu if the "encrypt my home directory" checkbox is ticked during installation), this bug can be triggered by an unprivileged user.
> прикольно. попытка увеличения защиты приводит к уменьшению защитыЭто накручивание наворотов на навороты, когда при дизайне и реализауии никто не смотрит на безопасность, приводит к "уменьшению защиты", а не "увеличение защиты", как подразумеваемя цель наворотов, как тебе показалось.
> Это накручивание наворотов на навороты, когда при дизайне и реализауии никто не
> смотрит на безопасность, приводит к "уменьшению защиты", а не "увеличение защиты",
> как подразумеваемАя цель наворотов, как тебе показалось.Фактическая цель этих FUSE-ов штопаных -- удобства, хоть разработчика - не писать "как надо", хоть пользователя "навороты!"ТМ. Поскольку думать о дизайне и безопасности ни в одну из этих фактических целей не входит, о безопасности думают __потом__ -- см. наверху.
fuse не имеет отношеня к ecryptfs-у. это отдельный оверлейный велосипед в ядре
> fuse не имеет отношеня к ecryptfs-у. это отдельный оверлейный велосипед в ядреОй, ты меня поймал. Ужос-ужос. Да я ошибся. Наверное.
Но на основной "тезис", извините, моего сообзщения оно никак не влияет. Шелушится синтаксический сахар про "разработчики сделали себе проще", ну, ладно.
Но с другой стороны в этом "балагане безопасности" думать о новом классе атак до того, как они "прилетели", объявлены и пожёваны, и дизайнить и кодить безопасноТМ, с оглядкой на них (на всех, ага), слегка невозможно. Когда Торвальдс прав, он прав. :/
Ммм, рассыпался мой выпад про навороты на навороты -- действительно, никто ж не ждал переполнения стека и испанской инквизиции. Кого бы обвинить? Фон Неймана с Кернигном?...
Прикольно. Все такие умные постфактум. Обязательно найдутся люди, которые пишут: "А я же горори-и-и-ил!"
Почему же - постфактум?
Подозреваю, большинство прочитавших новость просто пожали плечами: "ну, я этой хренью и не пользовался".
Lubuntu 16.04. Проверил обновления - никаких патчей не прилетело. Странно...
Шифровать домашние данные это паранойя,если уже такой параноик отключи комп от сети закинь туда свои данные и больше к нему нечего не подсоединяй....
Кстати еще можно больше не включать ПК точно не стырят данные.
А в чем проблема? Кто хочет, тот шифрует.
> Кстати еще можно больше не включать ПК точно не стырят данные.Забываешь про случай когда какой-нибудь шустрик скинет с твоего компа данные, если он остался без присмотра. Наиболее актуально для ноутов и мобильных устройств, но иногда так могут разуть и обычный компьютер.
В микроядре этого бы удалось избежать.
> В микроядре этого бы удалось избежать.Как? Перезагрузкой драйвера файловой системы, которую все фаны микроядер рассматривают как чуть ли не основне преимущество? Не смешите уж.
Драйвера в микроядре обычно в юзерспейсе и не могут привести к получению root.