The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Уязвимость в ядре Linux, позволяющая поднять привилегии через eCryptfs

21.06.2016 10:49

Исследователи безопасности из группы Zero, созданной компанией Google для предотвращения атак, совершаемых с использованием ранее неизвестных уязвимостей, раскрыли информацию о новой технике атаки (CVE-2016-1583) на ядро Linux. В качестве примера представлен эксплоит, позволяющий локальному пользователю поднять свои привилегии в системе, в которой применяется шифрование домашних директорий при помощи 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 в другое место. Соответствующие исправления уже приняты в состав ядра Linux, а также предложены дополнительные методы защиты. Обновления пакетов с ядром с устранением уязвимости уже выпущены для Ubuntu Linux, Debian и SUSE. Исправление для RHEL/CentOS 5/6 будет представлено в ближайшем обновлении (ветка 7 не подвержена проблеме).

  1. Главная ссылка к новости (http://googleprojectzero.blogs...)
  2. OpenNews: Google представил проект Zero, нацеленный на повышение защищённости Сети
  3. OpenNews: Продемонстрировано использование уязвимости в DRAM-памяти для повышения привилегий в системе
  4. OpenNews: В ядре Linux обнаружена уязвимость, позволяющая поднять привилегии в системе
  5. OpenNews: Уязвимость в ядре Linux, позволяющая запустить код при подключении USB-устройства злоумышленника
  6. OpenNews: Представлена отдельная ветка ядра Linux с устранением уязвимостей
Лицензия: CC-BY
Тип: Проблемы безопасности
Ключевые слова: linux, kernel, security
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (43) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, A.Stahl (ok), 11:42, 21/06/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    >поднять свои привилегии в системе, в которой применяется шифрование

    Чем больше секьюрности, тем меньше секьюрности. Иронично...

     
     
  • 2.2, й (?), 11:46, 21/06/2016 [^] [^^] [^^^] [ответить]  
  • +/
    есть мнение, что всё это fs-level-шифрование крайне ущербная штука, а для секюрности, надёжности и пр. надо использовать block level. по крайней мере, все мои опыты говорили именно об этом.
     
     
  • 3.5, Аноним (-), 12:06, 21/06/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Опыты показали, что ты все свои фс без ключа расшифровал? Иди получать медаль и назначение в фсб.
     
     
  • 4.13, Аноним (-), 13:34, 21/06/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А ты в ЦРУ. Ну хватит уже писать феерический бред.
     
     
  • 5.19, Аноним (-), 16:01, 21/06/2016 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Не я начал не я и хватать буду. У чела фс-левел шифрование несекьюрно, что тон неоднократно своимим опытами подтверждал. Пусть пруф выкатит или затнется.
     
     
  • 6.22, Аноним (-), 16:18, 21/06/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Поддержу этого анонима.
     
  • 6.27, й (?), 16:46, 21/06/2016 [^] [^^] [^^^] [ответить]  
  • +/
    у меня очень красиво эта самая ecryptfs рассыпалась и теряла файлы. раза три за полгода. после этого я использую только dm-crypt, с ним такой проблемы на том же железе не было ни разу.
     
     
  • 7.30, Аноним (-), 17:36, 21/06/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Как-то неправильно вы его используете.
     
     
  • 8.31, й (?), 17:54, 21/06/2016 [^] [^^] [^^^] [ответить]  
  • +/
    да используем нормально, ноут из саспенда не всегда просыпался, поэтому иногда н... текст свёрнут, показать
     
  • 7.36, Led (ok), 21:40, 21/06/2016 [^] [^^] [^^^] [ответить]  
  • –6 +/
    > у меня очень красиво эта самая ecryptfs рассыпалась и теряла файлы.

    Дураки должны страдать.

     
     
  • 8.42, Аноним (-), 07:43, 22/06/2016 [^] [^^] [^^^] [ответить]  
  • +3 +/
    А пользователи с рейтингом менее -11130 баллов должны подтираться вместе со всем... текст свёрнут, показать
     
     
  • 9.47, Аноним (-), 14:02, 22/06/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    На свой рейтинг посмотри ... текст свёрнут, показать
     
     
  • 10.49, Аноним (-), 17:09, 22/06/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Это рейтинг коллективного бессознательного, не считается ... текст свёрнут, показать
     
  • 3.28, Ivan_83 (ok), 16:50, 21/06/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Чем выше шифрование в стёке ФС тем лучше.
    Для файла можно один раз посчитать хэш, для блоков придётся считать много хэшей.
    Для файла нужен отдельный ключ/соль, для блоков - каждому отдельное.
     
  • 2.7, пучапучс (?), 12:59, 21/06/2016 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Да чуть-ли не норма.
    Самая хитрошифрованная система бессильна против пароля 123.
     
     
  • 3.23, Аноним (-), 16:19, 21/06/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Хитрошифрованная такой пароль поставить не даст.
     

  • 1.3, тоже Аноним (ok), 11:49, 21/06/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Уязвимость проявляется только в конкретном eCryptfs.
    В Убунте, например, он устанавливается ТОЛЬКО в том случае, если шифруется домашний каталог. Кто-нибудь этим вообще пользуется?

    Просто напомню: никаких уязвимостей в TrueCrypt под Linux так и не всплыло...

     
     
  • 2.14, Аноним (-), 13:37, 21/06/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Кто-нибудь этим вообще пользуется?

    Судя по интернет-форумам - пользуются. Тем более в инсталяторе есть конфигурилка.

    Там же главный аргумент против блочного шифрования всего раздела - зачем шифровать bin, если там много предсказуемых данных?

     
     
  • 3.15, тоже Аноним (ok), 13:53, 21/06/2016 [^] [^^] [^^^] [ответить]  
  • –4 +/
    У меня главный аргумент против шифрования чего бы то ни было другой.
    Зачем шифровать то, что совершенно незачем шифровать?
    Даже домашний раздел в основном занят информацией, не имеющей никакой ценности.
     
     
  • 4.21, Аноним (-), 16:17, 21/06/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Для того, чтобы было труднее обнаружить то, что шифровать есть зачем.
     
     
  • 5.25, тоже Аноним (ok), 16:30, 21/06/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Вы все еще прячете порно в Program Files?
    Ну, вот лежит у меня на самом видном месте файлик с расширением .tc (а на флешке - еще и его копия). Да, у меня тут кое-что лично мне дорогое спрятано (нет, не порно, отвлекитесь уже). В чем я прокололся?
     
     
  • 6.35, _ (??), 20:18, 21/06/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >В чем я прокололся?

    Дык! :)
    >Program Files

     
     
  • 7.43, тоже Аноним (ok), 09:03, 22/06/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Не-е, я хитрый. Я прячу Program Files в ~/.wine :)
     
  • 4.24, Aleks Revo (ok), 16:28, 21/06/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Информация из домашнего каталога приобретает ценность не до утечки, а после, когда тебя начинают ею шантажировать или на её основании выносится приговор "пожизненно с полной конфискацией".
     
     
  • 5.26, тоже Аноним (ok), 16:31, 21/06/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Например?
     
  • 4.29, Crazy Alex (ok), 17:14, 21/06/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Проще зашифровать всё, чем на каждый чих думать "а не дописал ли я сюда то, чот надо зашифровать" и "не зименились ли обстоятельства так, что надо шифровать половину того, что сейчас  в открытом виде лежит". Уж больно велики шансы забыть.
     
  • 2.41, t (??), 01:04, 22/06/2016 [^] [^^] [^^^] [ответить]  
  • +/
    т.е. за encfs можно не переживать?
     
     
  • 3.44, тоже Аноним (ok), 09:05, 22/06/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > т.е. за encfs можно не переживать?

    Полагаю, можно не переживать вообще. Условия для рвботы эксплойта дают не настолько большую потенциальную аудиторию, чтобы кто-то всерьез его использовал.

     

  • 1.4, Нанобот (ok), 12:06, 21/06/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    >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.

    прикольно. попытка увеличения защиты приводит к уменьшению защиты

     
     
  • 2.8, Andrey Mitrofanov (?), 13:13, 21/06/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >>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.
    > прикольно. попытка увеличения защиты приводит к уменьшению защиты

    Это накручивание наворотов на навороты, когда при дизайне и реализауии никто не смотрит на безопасность, приводит к "уменьшению защиты", а не "увеличение защиты", как подразумеваемя цель наворотов, как тебе показалось.

     
     
  • 3.9, Andrey Mitrofanov (?), 13:16, 21/06/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Это накручивание наворотов на навороты, когда при дизайне и реализауии никто не
    > смотрит на безопасность, приводит к "уменьшению защиты", а не "увеличение защиты",
    > как подразумеваемАя цель наворотов, как тебе показалось.

    Фактическая цель этих FUSE-ов штопаных -- удобства, хоть разработчика - не писать "как надо", хоть пользователя "навороты!"ТМ. Поскольку думать о дизайне и безопасности ни в одну из этих фактических целей не входит, о безопасности думают __потом__ -- см. наверху.

     
     
  • 4.16, Аноним (-), 14:03, 21/06/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    fuse не имеет отношеня к ecryptfs-у. это отдельный оверлейный велосипед в ядре
     
     
  • 5.48, Andrey Mitrofanov (?), 14:22, 22/06/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > fuse не имеет отношеня к ecryptfs-у. это отдельный оверлейный велосипед в ядре

    Ой, ты меня поймал. Ужос-ужос. Да я ошибся. Наверное.

    Но на основной "тезис", извините, моего сообзщения оно никак не влияет. Шелушится синтаксический сахар про "разработчики сделали себе проще", ну, ладно.

    Но с другой стороны в этом "балагане безопасности" думать о новом классе атак до того, как они "прилетели", объявлены и пожёваны, и дизайнить и кодить безопасноТМ, с оглядкой на них (на всех, ага), слегка невозможно.  Когда Торвальдс прав, он прав. :/

    Ммм, рассыпался мой выпад про навороты на навороты -- действительно, никто ж не ждал переполнения стека и испанской инквизиции. Кого бы обвинить? Фон Неймана с Кернигном?...

     

  • 1.17, Аноним (-), 14:25, 21/06/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Прикольно. Все такие умные постфактум. Обязательно найдутся люди, которые пишут: "А я же горори-и-и-ил!"
     
     
  • 2.18, тоже Аноним (ok), 14:38, 21/06/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Почему же - постфактум?
    Подозреваю, большинство прочитавших новость просто пожали плечами: "ну, я этой хренью и не пользовался".
     

  • 1.32, iLex (ok), 18:53, 21/06/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Lubuntu 16.04. Проверил обновления - никаких патчей не прилетело. Странно...
     
  • 1.33, Professor (??), 19:41, 21/06/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Шифровать домашние данные это паранойя,если уже такой параноик отключи комп от сети закинь туда свои данные и больше к нему нечего не подсоединяй....
    Кстати еще можно больше не включать ПК точно не стырят данные.  
     
     
  • 2.39, Аноним (-), 21:54, 21/06/2016 [^] [^^] [^^^] [ответить]  
  • +/
    А в чем проблема? Кто хочет, тот шифрует.
     
  • 2.46, Аноним (-), 13:59, 22/06/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Кстати еще можно больше не включать ПК точно не стырят данные.  

    Забываешь про случай когда какой-нибудь шустрик скинет с твоего компа данные, если он остался без присмотра. Наиболее актуально для ноутов и мобильных устройств, но иногда так могут разуть и обычный компьютер.

     

  • 1.38, Аноним (-), 21:53, 21/06/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    В микроядре этого бы удалось избежать.
     
     
  • 2.45, Аноним (-), 13:26, 22/06/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > В микроядре этого бы удалось избежать.

    Как? Перезагрузкой драйвера файловой системы, которую все фаны микроядер рассматривают как чуть ли не основне преимущество? Не смешите уж.

     
     
  • 3.50, Аноним (-), 09:14, 23/06/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Драйвера в микроядре обычно в юзерспейсе и не могут привести к получению root.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру