The OpenNET Project / Index page

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

10.01.2011 13:27  Анализ безопасности показал переоценку защиты с использованием "capabilities"

Брэд Спенглер (Brad Spengler), автор проекта grsecurity, представил отчет с результатами оценки надежности системы "capabilities" в Linux, предназначенной для выборочного предоставления определенных привилегированных действий или открытия доступа к определенным ресурсам (например, утилите ping можно открыть только доступ к raw-сокету, без делегирования остальных root-прав). Проведенное исследование показало неожиданные результаты: 19 из 35 существующих "capabilities" позволили совершить действия, которые в конечном итоге потенциально могут привести к получению полноценных прав пользователя root.

Для каждого из девятнадцати проблемных "capabilities" представлен метод получения прав полноценного суперпользователя в ситуации эксплуатации непривилегированных приложений, для которых выставлен только один из флагов "capabilities". Несмотря на то, что многие из методов расширения привилегий через проблемные "capabilities" имеют теоретический характер и требуют для эксплуатации определенных условий, по мотивам исследования уже подготовлен рабочий эксплоит, демонстрирующий процесс расширения флага CAP_SYS_ADMIN до полноценного root-доступа. Эксплоит работает только на 32-разрядных системах с Linux-ядром до версии 2.6.35 (например, Ubuntu 10.10) и дополнительно использует ошибку в реализации протокола Phonet.

Эксплоит использует CAP_SYS_ADMIN в сочетании с передачей отрицательного индекса протокола для подстановки серии фиктивных структур на уровне пользователя и инкрементирования произвольного адреса в ядре, что в конечном итоге позволяет выполнить код на уровне ядра. Представленный в эксплоите метод намеренно усложнен для демонстрации наличия не очевидных вариантов. В простейшем случае, имея права CAP_SYS_ADMIN, можно примонтировать собственную файловую систему поверх части текущей ФС. Другие варианты - осуществить подстановку команд в открытый администратором shell через формирование TIOCSTI ioctl к /dev/tty или перенаправить сетевой порт для переброса SSH-запросов на свой обработчик, предназначенный для сбора паролей.

Примечательно, что статья о недостатках "capabilities" опубликована во время начала воплощения в жизнь инициативы по замене suid-бита на "capabilities" во всех программах будущих релизов Ubuntu и Fedora. Ожидалось, что переход на "capabilities" позволит понизить опасность от эксплуатации уязвимостей в приложениях, требующих расширенных привилегий, что в итоге значительно повысит безопасность системы. В ситуации когда большинство "capabilities" позволяют обходными путями теоретически получить root-доступ, в сочетании с ранее публиковавшимися предупреждениями о необходимости переработки и аудита кода некоторых программ для полноценной поддержки "capabilities", итог инициатив по полному уходу от suid-бита может отрицательно сказаться на безопасности. В частности, приводится пример, когда suid-утилита на начальной стадии своей работы выполняет требующее повышенных привилегий действие и затем сразу сбрасывает повышенные привилегии. Если в такой утилите заменить suid на "capabilities" без добавления кода сброса полученных привилегий, то данные привилегии останутся доступны на протяжении всего времени работы программы.

В качестве примеров приложений, для защиты которых используется хотя бы один проблемный флаг "capabilities" приводятся:

  • rsyslogd/syslogd (CAP_SYS_ADMIN, CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH)
  • cron (CAP_SETUID, CAP_SETGID)
  • login (CAP_SETUID, CAP_SETGID, CAP_FSETID, CAP_CHOWN)
  • cvs (CAP_DAC_OVERRIDE, CAP_SETUID, CAP_FSETID)
  • postfix (CAP_DAC_OVERRIDE, CAP_KILL, CAP_SETUID, CAP_SETGID, CAP_SYS_CHROOT)
  • apache (CAP_KILL, CAP_SETUID, CAP_SETGID)
  • sshd (CAP_KILL, CAP_SYS_TTY_CONFIG, CAP_SETUID, CAP_SETGID, CAP_CHOWN)
  • xinetd (CAP_SETUID, CAP_SETGID)
  • procmail (CAP_SETUID, CAP_SETGID, CAP_DAC_OVERRIDE)

Проблемные "capabilities" (стоит отметить, что в списке представлены достаточно редко используемые или очевидно небезопасные флаги):

  • CAP_SYS_ADMIN - включает достаточно широкий спектр административных операций, включая монтирование ФС, управление квотами и т.п. Методы расширений привилегий были представлены выше;
  • CAP_SYS_TTY_CONFIG - можно изменить раскладку клавиатуры для терминала администратора, что в конечном итоге может быть использовано для выполнения не той команды, которая подразумевалась (rm вместо ls);
  • CAP_MKNOD - можно создать доступное пользователю на запись блочное устройство, которое будет отождествлено с рабочим системным диском;
  • CAP_SYS_PTRACE - можно выполнить подстановку кода в процессе выполнения трассировки привилегированного процесса;
  • CAP_SYS_RAWIO - можно выполнить маппинг NULL-страницы для эксплуатации повсеместно встречающихся уязвимостей, связанных с разыменованием NULL-указателей. Также возможно совершение атак через FIBMAP ioctl;
  • CAP_SYS_MODULE - позволяет модифицировать ядро;
  • CAP_SETFCAP - имея полный доступ к файлам, легко получить полный root-доступ;
  • CAP_FSETID, CAP_SETGID - можно получить привилегии GID 0 или GID staff, а затем модифицировать некоторые системные файлы доступные на запись для данных GID (например, содержимое /usr/local в Debian);
  • CAP_SETUID - не запрещает сменить id на 0;
  • CAP_DAC_OVERRIDE - можно модифицировать бинарный файл, который затем будет запущен пользователем root;
  • CAP_SETPCAP - позволяет организовать сохранение установленных "capabilities" для дочерних процессов;
  • CAP_IPC_OWNER - позволяет контролировать содержимое приватных данных в IPC;
  • CAP_FOWNER, CAP_CHOWN - можно поменять права доступа на такие файлы, как /etc/shadow и /root/.ssh/*;
  • CAP_SYS_CHROOT - можно подготовить chroot-окружение с подставным libc и организовать проброс из него жесткой ссылки на внешний suid root-файл, при выполнении которого в chroot функции подмененной libc будут выполнены с root-правами;
  • CAP_DAC_READ_SEARCH - можно прочитать содержимое /etc/shadow и /root/.ssh/*;
  • CAP_SYS_BOOT - можно загрузить подставное ядро через систему kexec_load;
  • CAP_AUDIT_CONTROL - можно задействовать netlink-команды AUDIT_TTY_GET/AUDIT_TTY_SET для логгирования ввода/вывода для заданного tty и перехватить таким образом пароль root.

"Capabilities" допускающие проведение некоторых видов атак:

  • CAP_KILL - можно завершить процесс, обслуживающий сетевой порт c номером выше 1024 и запустить вместо него свой обработчик;
  • CAP_NET_ADMIN - позволяет организовать перенаправление сетевого порта на свой обработчик;
  • CAP_NET_RAW - позволяет организовать сниффинг транзитного трафика с целью выявления паролей.
  • "Capabilities" для которых пока не найдено обходных путей:
    • CAP_LINUX_IMMUTABLE
    • CAP_NET_BROADCAST
    • CAP_NET_BIND_SERVICE;
    • CAP_IPC_LOCK
    • CAP_SYS_PACCT
    • CAP_SYS_NICE;
    • CAP_SYS_RESOURCE
    • CAP_SYS_TIME
    • CAP_LEASE
    • CAP_AUDIT_WRITE
    • CAP_MAC_OVERRIDE
    • CAP_MAC_ADMIN
    • CAP_SYSLOG


    1. Главная ссылка к новости (http://forums.grsecurity.net/v...)
    2. OpenNews: Fedora на пути полного ухода от использования suid-программ в дистрибутиве
    3. Замена setuid-бита на capabilities для системных программ в Linux
    Лицензия: CC-BY
    Тип: Проблемы безопасности
    Ключевые слова: security, capabilities, linux, limit, attack
    При перепечатке указание ссылки на opennet.ru обязательно
    Обсуждение Ajax/Линейный | Показать все | RSS
     
  • 1.1, zazik, 13:39, 10/01/2011 [ответить] [смотреть все]    [к модератору]
  • +1 +/
    Мне кажется или здесь попахивает Капитаном?
     
     
  • 2.10, szh, 15:01, 10/01/2011 [^] [ответить] [смотреть все] [показать ветку]    [к модератору]
  • +1 +/
    кажется
     
  • 1.3, User294, 13:57, 10/01/2011 [ответить] [смотреть все]    [к модератору]
  • –4 +/
    Судя по названию capabillities, Капитан чего-то озаботился capabilities... :)
     
     
  • 2.4, zazik, 14:09, 10/01/2011 [^] [ответить] [смотреть все] [показать ветку]     [к модератору]
  • +2 +/
    Я к тому, что, получив capabilities на SETUID, приложение вполне ожидаемо может ... весь текст скрыт [показать] [показать ветку]
     
  • 1.5, Vasily Pupkin, 14:23, 10/01/2011 [ответить] [смотреть все]    [к модератору]  
  • +/
    Дык а какого черта приложения не сбрасывают свои capabilites после того, как выполнят необходимые действия?
     
     
  • 2.12, pavlinux, 15:07, 10/01/2011 [^] [ответить] [смотреть все] [показать ветку]     [к модератору]  
  • +2 +/
    У трояна тоже это будешь спрашивать Какой нихароший, не сбросил свои капабил... весь текст скрыт [показать] [показать ветку]
     
     
  • 3.15, Vasily Pupkin, 16:27, 10/01/2011 [^] [ответить] [смотреть все]    [к модератору]  
  • +2 +/
    Причем тут троян? :) Вы надавали трояну капы == вы надавали трояну suid/root.
     
  • 2.21, Frank, 08:02, 11/01/2011 [^] [ответить] [смотреть все] [показать ветку]    [к модератору]  
  • +/
    А если они ещё нужны? Уже сброшенное обратно не вернёшь...
     
     
  • 3.22, zazik, 09:25, 11/01/2011 [^] [ответить] [смотреть все]     [к модератору]  
  • +/
    А для чего такое может понадобится Сделал дело - отдай capabilities Иначе SETU... весь текст скрыт [показать]
     
  • 3.28, Michael Shigorin, 12:16, 15/01/2011 [^] [ответить] [смотреть все]     [к модератору]  
  • +/
    То отделяют worker ов с уже пониженными привилегиями от процесса, который держит... весь текст скрыт [показать]
     
  • 1.6, Аноним, 14:33, 10/01/2011 [ответить] [смотреть все]     [к модератору]  
  • +/
    Собственно, ничего страшного Вполне себе осмысленный анализ, который говорит, ч... весь текст скрыт [показать]
     
     
  • 2.8, szh, 14:52, 10/01/2011 [^] [ответить] [смотреть все] [показать ветку]     [к модератору]  
  • +1 +/
    не у некоторых , а у большинства, что в корне меняет дело Усложнять систему ра... весь текст скрыт [показать] [показать ветку]
     
  • 2.9, Аноним, 14:58, 10/01/2011 [^] [ответить] [смотреть все] [показать ветку]     [к модератору]  
  • +5 +/
    Проблема в том, что большая часть suid-прог сбрасывают привилегии на начальной ф... весь текст скрыт [показать] [показать ветку]
     
  • 2.11, PereresusNeVlezaetBuggy, 15:06, 10/01/2011 [^] [ответить] [смотреть все] [показать ветку]     [к модератору]  
  • +/
    Читайте внимательнее SUID-программа может сбросить свои привилегии и нормальны... весь текст скрыт [показать] [показать ветку]
     
     
  • 3.13, цацуа, 15:49, 10/01/2011 [^] [ответить] [смотреть все]     [к модератору]  
  • +3 +/
    Беглый поиск по гуглу показал, что Each thread has three capability sets contai... весь текст скрыт [показать]
     
     
  • 4.17, PereresusNeVlezaetBuggy, 16:43, 10/01/2011 [^] [ответить] [смотреть все]     [к модератору]  
  • +3 +/
    Угу, вот собсно код проверки в kernel capability c, capset 2 code if get_us... весь текст скрыт [показать]
     
     
  • 5.20, Michael Shigorin, 23:47, 10/01/2011 [^] [ответить] [смотреть все]     [к модератору]  
  • +/
    До кучи http seclists org oss-sec 2010 q4 123 http www lst de okir blackha... весь текст скрыт [показать]
     
     ....нить скрыта, показать (6)

  • 1.7, Аноним, 14:33, 10/01/2011 [ответить] [смотреть все]    [к модератору]  
  • +6 +/
    Молодец дядька. В который раз уже молодец. Стабильно раз в год показывает преимущества своего проекта над всеми остальными системами безопасности GNU/Linux. Пойду-ка зашлю ему ещё деньжат.
     
     
  • 2.16, Vasily Pupkin, 16:32, 10/01/2011 [^] [ответить] [смотреть все] [показать ветку]    [к модератору]  
  • +1 +/
    Всё должно пребывать в гармонии. GRSecurity это конечно хорошо, но в ванильке его не будет
     
  • 1.14, анонимиус, 16:20, 10/01/2011 [ответить] [смотреть все]    [к модератору]  
  • –1 +/
    В том виде, в каком оно существует(capabilities), оно уже похоже на костыль. Возможно не прав, глубоко не вникал, но как-то так.
     
  • 1.18, анон, 16:49, 10/01/2011 [ответить] [смотреть все]    [к модератору]  
  • +1 +/
    А solaris privileges это тоже касается?
    В солярке, afaik, на привилегиях практически вся безопасность завязана, а по сути это те же самые capabilities.
     
     
  • 2.23, letsmac, 00:02, 12/01/2011 [^] [ответить] [смотреть все] [показать ветку]     [к модератору]  
  • –5 +/
    Ну и в винде примерно аналогично Для каждого потока создается свой уровень дост... весь текст скрыт [показать] [показать ветку]
     
     
  • 3.24, non anon, 10:20, 12/01/2011 [^] [ответить] [смотреть все]    [к модератору]  
  • +/
    > для соляры со своими версиями программ - очень даже безопасная

    Это почему? Принципы-то те же.

    > Так глядишь и ACL нормальный у пингвинов появится.

    А что, сейчас они не нормальные?

     
     
  • 4.25, ананим, 13:16, 12/01/2011 [^] [ответить] [смотреть все]    [к модератору]  
  • +1 +/
    >> Так глядишь и ACL нормальный у пингвинов появится.
    >А что, сейчас они не нормальные?

    да это просто была стандартная попытка неуча заполучить очки, смешав в кучу слабо понимаемые им понятия - ACL, MAC, RBAC, MLS, MIC и пр., и пр. ну и капабилитис до кучи.

     
     
  • 5.26, letsmac, 23:40, 12/01/2011 [^] [ответить] [смотреть все]    [к модератору]  
  • +/
    > да это просто была стандартная попытка неуча заполучить очки, смешав в кучу
    > слабо понимаемые им понятия - ACL, MAC, RBAC, MLS, MIC и

    Это один фиг только "больше и толще и современнее".  Капабилитис из той же кучи с той же задачей разграничения прав только для приложений. Еще один балаган c аббревиатурами.  

     
     
  • 6.27, ананим, 00:01, 13/01/2011 [^] [ответить] [смотреть все]    [к модератору]  
  • +/
    выражение "один фиг" - это тупые коментарии недоучек, пытающихся выдать своё невежество за активную гражданскую позицию.
    даже спорить с такими - это неуважение к себе любимому.

    зы:
    отмечу только один факт https://www.opennet.ru/man.shtml?topic=capabilities
    >Начиная с ядра 2.2, Linux обеспечивает (хотя и не полностью) в системе много возможностей, разделяющие привилегии, традиционно ассоциированные с суперпользователем, в отдельный блок, который может быть независимо включен или выключен.

    http://ru.wikipedia.org/wiki/Linux_(%D1%8F%D0%B4%D1%80%D0%BE)
    >25 января 1999 — Linux версии 2.2.0, изначально довольно недоработанный (1 800 847 строк кода).

    так что это такая уже древность, что все ваши инсинуации по данному вопросу просто смешны.
    при чем они так и не входят в posix стандарт, в который ACL принят (тем более реализован) аж в 1998 году.

     

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


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