The OpenNET Project / Index page

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

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

10.01.2011 13:27

Брэд Спенглер (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 3.0
    Короткая ссылка: https://opennet.ru/29219-security
    Ключевые слова: security, capabilities, linux, limit, attack
    При перепечатке указание ссылки на opennet.ru обязательно


    Обсуждение (26) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, zazik (ok), 13:39, 10/01/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Мне кажется или здесь попахивает Капитаном?
     
     
  • 2.10, szh (ok), 15:01, 10/01/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    кажется
     

  • 1.3, User294 (ok), 13:57, 10/01/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Судя по названию capabillities, Капитан чего-то озаботился capabilities... :)
     
     
  • 2.4, zazik (ok), 14:09, 10/01/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Судя по названию capabillities, Капитан чего-то озаботился capabilities... :)

    Я к тому, что, получив capabilities на SETUID, приложение вполне ожидаемо может сделать SETUID. И т.д.

     

  • 1.5, Vasily Pupkin (?), 14:23, 10/01/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Дык а какого черта приложения не сбрасывают свои capabilites после того, как выполнят необходимые действия?
     
     
  • 2.12, pavlinux (ok), 15:07, 10/01/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    У трояна тоже это будешь спрашивать... "Какой нихароший, не сбросил свои капабилитес"
     
     
  • 3.15, Vasily Pupkin (?), 16:27, 10/01/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Причем тут троян? :) Вы надавали трояну капы == вы надавали трояну suid/root.
     
  • 2.21, Frank (ok), 08:02, 11/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    А если они ещё нужны? Уже сброшенное обратно не вернёшь...
     
     
  • 3.22, zazik (ok), 09:25, 11/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > А если они ещё нужны? Уже сброшенное обратно не вернёшь...

    А для чего такое может понадобится? Сделал дело - отдай capabilities. Иначе SETUID лучше.

     
  • 3.28, Michael Shigorin (ok), 12:16, 15/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > А если они ещё нужны? Уже сброшенное обратно не вернёшь...

    То отделяют worker'ов с уже пониженными привилегиями от процесса, который держит привилегии и порождает worker'ов, но старается не вляпаться сам.

     

  • 1.6, Аноним (-), 14:33, 10/01/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Собственно, ничего страшного. Вполне себе осмысленный анализ, который говорит, что у некоторых capabilities в определенных ситуацияз могут быть проблемы. Но все равно это гораздо лучше чем суидная прога, которая при эксплойте может получить все права. Так что федора и убунту могут спокойно заниматься переводом с суид дальше, смысл от этого есть, надо только учесть то что тут обнаружено.
     
     
  • 2.8, szh (ok), 14:52, 10/01/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    не у "некоторых", а у большинства, что в корне меняет дело. Усложнять систему ради минимальной пользы глупо.
     
  • 2.9, Аноним (-), 14:58, 10/01/2011 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > Но все равно это гораздо лучше чем суидная прога, которая при эксплойте может получить все права.

    Проблема в том, что большая часть suid-прог сбрасывают привилегии на начальной фазе инициализации, а деятели из Fedora/Ubuntu этого не учитывают и заменяют suid на capabilities без добавления в код сброса capabilities, поэтому в итоге вместо кучи suid-программ, которые можно эксплуатировать на начальной стадии работы (например, через дыру в libc), получаем кучу программ для которых capabilities включены постоянно и эксплуатировать их можно на любой стадии их работы. Например, сломав ping получим возможность неограниченного сниффинга трафика, а httpd - возможность биндить на любой нижний порт.

     
  • 2.11, PereresusNeVlezaetBuggy (ok), 15:06, 10/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Читайте внимательнее: SUID-программа может сбросить свои привилегии (и нормальные программы так и делают после запуска), после чего становится "не опасной". Тот же ping, например: открывает сырой сокет с рутовыми привилегиями, дропает привилегии и дальше работает из-под юзера.

    А вот в случае с capabilities, насколько удалось понять[1], это невозможно: можно лишь перманентно отнять соответствующую привилегию у программы, другой программой, имеющей спецпривилегию CAP_SETPCAP. То есть «безопасность» получается — это когда ты запускаешь прогу, пытаешься угадать, когда же она закончит требующую рутовых прав инициализацию, и затем отдельной прогой убираешь соответствующие привилегии. Думаю, не надо объяснять, насколько это криво...

    --
    [1] http://www.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.2/capfaq-0

     
     
  • 3.13, цацуа (?), 15:49, 10/01/2011 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Беглый поиск по гуглу показал, что:

    Each thread has three capability sets containing zero or more of the above capabilities:
    Permitted:
    This is a limiting superset for the effective capabilities that the thread may assume. It is also a limiting superset for the capabilities that may be added to the inheritable set by a thread that does not have the CAP_SETPCAP capability in its effective set.
    If a thread drops a capability from its permitted set, it can never re-acquire that capability (unless it execve(2)s either a set-user-ID-root program, or a program whose associated file capabilities grant that capability).


    То есть вполне очевидно что сбросить эти флажки можно, ровно в том же духе что и суид.
    Таким образом, разработчикам федоры да убунты просто стоит позаботиться о том чтобы пропатчить код суидных программ - дропать capabilities вместо suid/sgid/

     
     
  • 4.17, PereresusNeVlezaetBuggy (ok), 16:43, 10/01/2011 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > То есть вполне очевидно что сбросить эти флажки можно, ровно в том
    > же духе что и суид.
    > Таким образом, разработчикам федоры да убунты просто стоит позаботиться о том чтобы
    > пропатчить код суидных программ - дропать capabilities вместо suid/sgid/

    Угу, вот собсно код проверки в kernel/capability.c, capset(2):



    if (get_user(pid, &header->pid))
    return -EFAULT;

    /* may only affect current now */
    if (pid != 0 && pid != task_pid_vnr(current))
    return -EPERM;

    И код обновления привилегий в security/commoncap.c:



    int cap_capset(struct cred *new,
           const struct cred *old,
           const kernel_cap_t *effective,
           const kernel_cap_t *inheritable,
           const kernel_cap_t *permitted)
    {
    if (cap_inh_is_capped() &&
        !cap_issubset(*inheritable,
      cap_combine(old->cap_inheritable,
          old->cap_permitted)))
    /* incapable of using this inheritable set */
    return -EPERM;

    if (!cap_issubset(*inheritable,
      cap_combine(old->cap_inheritable,
          old->cap_bset)))
    /* no new pI capabilities outside bounding set */
    return -EPERM;

    /* verify restrictions on target's new Permitted set */
    if (!cap_issubset(*permitted, old->cap_permitted))
    return -EPERM;

    /* verify the _new_Effective_ is a subset of the _new_Permitted_ */
    if (!cap_issubset(*effective, *permitted))
    return -EPERM;

    new->cap_effective   = *effective;
    new->cap_inheritable = *inheritable;
    new->cap_permitted   = *permitted;
    return 0;
    }

    Значит, претензия действительно чисто к невнимательным товарищам из Ubuntu & Co.

     
     
  • 5.20, Michael Shigorin (ok), 23:47, 10/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    До кучи:
    http://seclists.org/oss-sec/2010/q4/123
    http://www.lst.de/~okir/blackhats/node125.html
    http://tldp.org/HOWTO/Secure-Programs-HOWTO/minimize-privileges.html
     

  • 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 (ok), 00:02, 12/01/2011 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Ну и в винде примерно аналогично. Для каждого потока создается свой уровень доступа. Технология очень сложная в разрешении противоречий. Для  linux -  новая -  для соляры со своими версиями программ - очень даже безопасная. Так глядишь и ACL нормальный у пингвинов появится.
     
     
  • 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 (ok), 23:40, 12/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > да это просто была стандартная попытка неуча заполучить очки, смешав в кучу
    > слабо понимаемые им понятия - ACL, MAC, RBAC, MLS, MIC и

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

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

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

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

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

     

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



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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