Редактор Habrahabr, Geektimes
0,0
рейтинг
20 января в 00:46

Разработка → В ядре Linux обнаружили уязвимость, позволяющую получить права суперпользователя



Практически все версии ядра Linux, от 3.8 до 4.5 (в git) подвержены достаточно серьезной уязвимости, которая дает возможность локальному юзеру получить права суперпользователя. Оказывается, уязвимость CVE-2016-0728 существует с 2012 года, а наиболее подвержены риску пользователи ОС Android. дело в том, что код приложений и игр, созданных с использованием NDK (Native Development Kit) и выложенных в Google Play, компания Google проверить не может.

Что касается ПК и серверов, то здесь ситуация не такая сложная, в особенности, если в системе всего один пользователь. Кроме того, не является слишком опасной эта уязвимость и тогда, если пользователям запрещено исполнять код, либо же различные экземпляры ОС находятся в среде виртуализации.

Уязвимость была обнаружена специалистами в keyrings, подсистеме ядра, которая отвечает за кэширование и хранение как ключей аутентификации, так и сертификатов для шифрования. При условии некорректного освобождения объектов возможно обращение к уже освобожденной области памяти в то время, когда процесс заменяет текущий keyrings сессии таким же экземпляром. Интересно, что код для эксплуатации найденной уязвимости довольно простой и состоит всего из 100 строк на С. Время выполнения эксплоита — полчаса.

Вся информация по проблеме доступна здесь — CVE-2016-0728. Сейчас обновления пакетов с ядром, ликвидирующие уязвимость, выпущены только разработчиками Debian.
marks @marks
карма
170,2
рейтинг 0,0
Редактор Habrahabr, Geektimes
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (42)

  • +1
    У меня первая ссылка в тексте («подвержены достаточно серьезной уязвимости») заблокирована провайдером — редиректит на zapret-info.at-home.ru

    У кого-то ещё так же?
    • +1
      http://webcache.googleusercontent.com/search?q=cache:QRFT7S9qim0J:perception-point.io/2016/01/14/analysis-and-exploitation-of-a-linux-kernel-vulnerability-cve-2016-0728/+&cd=2&hl=ru&ct=clnk&gl=ru
    • +25
      Это национальный способ борьбы с уязвимостями: заблокируем и они не пройдут.
      • +3
        У меня одного заблокирована большая часть ресурсов о кодинге и IT, типа paulirish.com, но доступны сайты с порно, казино и лечением мочёй? Программирование теперь стало опасным для государственной безопасности?
        • +12
          Конечно, программисты же могут заменить целые министерства.
        • +4
          perception-point.io — у меня открывается, а paulirish.com — тоже заблокирован.

          PS недавно узнал причину блокировки steps3d.narod.ru, оказалась причина блокировки в том, что автор — сторонник легализации короткоствола. То есть сайт заблокирован не за примеры с OpenGL, а за то что его сочли «экстремистским». Так что возможно, на paulirish.com — тоже нашли что-то подобное.
        • 0
          Кто ж его знает ).
          Я Java-разработчик, всё что надо — вроде работает.
          paulirish.com и perception-point.io тоже работают :)
          У остальных — не знаю
  • 0
    Я правильно понимаю, что приода уязвимости такова, что:
    1. Успешная эксплуатация носит вероятностный характер
    2. Неудачная эксплуатация никак не повлияет на уязвимую систему. В отличие от переполнений буфера или повреждения памяти, которые в случае неудачной эксплуатации приводят к отказу в обслуживании и\или перезагрузке системы
    • +9
      Смысл атаки такой:
      1. Есть функция, которая держит кусок памяти с рефкаунтом. Счётчик — int 32-битный, вне зависимости от того, amd64 у вас или нет.
      2. Если увеличить счётчик на 2^32 раз, то он переполнится и начнёт расти с нуля. Когда счётчик будет равен нулю, ядро память освободит, но структурка со счётчиком ещё будет жить, мы ссылку на неё в юзерспейсе держим.
      3. Как только память освободилась, нужно туда что нибудь записать, для этого нужно выделать память такого же размера. Вот тут тонкий момент — память нужно выделить сразу после того, как память будет освобождена, и выделить нужно кусочек такого же размера. Авторы эксплоита применяют для этого msgsnd. В структуре много указателей на функции, они записывают вместо одной из них (а именно — revoke) свою функцию userspace_revoke.
      4. А дальше остаётся только вызвать revoke, который в итоге выполнит userspace_revoke.
      • 0
        Работа с указателями и памятью подразумевает отказ в обслуживании в случае неудачной работы эксплоита?
        • +2
          Не должно, потому что всё подчищается корректно, ссылка просто пропадает на тот, уже неиспользуемый, кусок памяти. В этом эксплоите используется особенность аллокатора памяти, чтобы записать данные в тот самый кусок, а не брутфорс, как это бывает обычно в случае с переполнением буфера.
        • 0
          Я тут подумал и понял, что действительно, можно случайно что-то поломать. Если этот кусочек памяти отдадут другому процессу, и он туда запишет мусор, то при вызове функций keyring для этой сессии может произойти упячка.
  • 0
    Собрал под Ubuntu 14.04.3 LTS

    uname -a
    Linux ubuntu 3.13.0-74-generic #118-Ubuntu SMP Thu Dec 17 22:52:10 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
    


    sudo apt-get install libkeyutils-dev
    gcc cve_2016_0728.c -o cve_2016_0728 -lkeyutils -Wall
    ./cve_2016_0728 PP_KEY
    

    Получил (30 минут):
    uid=1000, euid=1000
    Increfing...
    finished increfing
    forking...
    finished forking
    caling revoke...
    uid=1000, euid=1000
    


    но прав root не получил…
    • +1
      Возможно, причина описана здесь, и в Ubuntu есть необходимый функционал в ядре?
      • 0
        Подсистема ядра keyrings насколько я понял присутствует или вопрос про что то иное?
        • +1
          Я про «many kernels have SMEP/SMAP enabled»
          • 0
            Собственно вот:
            If you check:
            root@eben:/proc# cat keys
            075e0cb4 IR-Q--- 63 expd 3f3f3f3f 1000 1001 keyring PP1: empty
            16477452 I--Q--- 3 perm 1f3f0000 1000 65534 keyring _uid.1000: empty
            19c6487a I--Q--- 21 perm 3f030000 1000 1001 keyring _ses: 1
            2ad3452d I--Q--- 1 perm 1f3f0000 0 65534 keyring _uid_ses.0: 1
            36d1aaca I--Q--- 2 perm 1f3f0000 0 65534 keyring _uid.0: empty
            root@eben:/proc#

            You will see it created the key. However if you check this — /proc/PID/smaps

            example:
            root@eben:/proc# find. -name «smaps»
            ./1/task/1/smaps
            ./1/smaps
            ./2/task/2/smaps
            ./2/smaps
            ./3/task/3/smaps
            ./3/smaps
            ./5/task/5/smaps

            It's probably not going to work because SMAP ( Supervisor Mode Access Prevention ) is enabled within the running kernel. Which will only trigger /bin/sh with the current UID.

            Hence in the release doc — Mitigations & Conclusions
            The vulnerability affects any Linux Kernel version 3.8 and higher. SMEP & SMAP will make it difficult to exploit as well as SELinux on android devices. Maybe we’ll talk about tricks to bypass those mitigation in upcoming blogs, anyway the most important thing for now is to patch it as soon as you can.


            Вы правы. SMAP включен что и не позволяет эксплуатировать уязвимость.
    • 0
      Судя по этой информации проблема была только у ubuntu 15.10, но на данный момент она исправлена.
      • 0
        Ну, как сказать… Wily, Vivid, Utopic и Trusty, и даже Precise с Trusty HWE: http://people.canonical.com/~ubuntu-security/cve/2016/CVE-2016-0728.html :)

        У них просто USN выпускаются на продукт (пара дистрибутив-пакет), а не на уязвимость.
    • 0
      вам нужно копать в сторону commit_creds и prepare_kernel_cred
    • 0
      alex:/tmp> ./exp PP1
      uid=1000, euid=1000
      Increfing…
      finished increfing
      forking…
      finished forking
      caling revoke…
      uid=1000, euid=1000

      sh-4.3$ whoami
      alex

      sh-4.3$ uname -a
      Linux alex-work 4.3.3-2-ARCH #1 SMP PREEMPT Wed Dec 23 20:09:18 CET 2015 x86_64 GNU/Linux
    • 0
      Простите, но что вы передали эксплоиту вместо PP_KEY?? )))
      • 0
        keyctl(KEYCTL_JOIN_SESSION_KEYRING, keyring_name)
        

        Это параметр keyring_name. Ключевое имя программы работающей из под root. Как его найти я пока не понял.
        • –1
          Первая же ссылка в статье)

          UPD.
          Дам подсказку: leak.c
          • –1
            Скомпилил. Получил. Исходя из этого подставил значения. Результат тот же.
          • 0
            Нет. Это любая строка символов. Можете использовать любой из списка
            cat /proc/keys (предпоследний столбец, без ':' )
            или задать свой. А далее, параллельно с запуском PoC эксплойта наблюдать как увеличивается третий столбец в строчке с Вашим keyring'ом:
            watch cat /proc/keys
            • +1
              Лучше уже использовавшийся не подавать, в эксплоите специально последние 5 итераций делают в выделенном цикле, чтобы сразу память занять. Правда мы с коллегами на разных машинах запускали, в том числе без SMEP, и пока ни разу не сработало. Но на гитхабе как минимум 1 человек отписался, что у него эксплоит сработал.

              Вот вечно с этими линуксами проблемы, даже эксплоиты не могут нормально работать :)
  • +6
    Я бы больше за Android'ы переживал.
    • +7
      Нет худа без добра: части андроид-девайсов это принесёт радость root'а
      • 0
        Малому числу, так как одновременно с использованием ядер 3 и старше версий в Android повсеместно начали использовать SELinux, и он режет на корню такие эксплойты.
  • 0
    openSUSE Tumbleweed
    4.4.0-1-default #1 SMP PREEMPT Mon Jan 11 14:46:34 UTC 2016 (83948c1) x86_64 x86_64 x86_64 GNU/Linux

    Не удалось получить рута.
  • 0
    Slackware-14.1
    $uname -a
    Linux darkstar 3.10.17 #2 SMP Wed Oct 23 16:34:38 CDT 2013 x86_64 Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz GenuineIntel GNU/Linux
    

    Не работает.
    • –1
      Говорил уже об этом выше. Вы просто передаёте строку PP_KEY на вход эксплоита… А нужно именно этот ключ. Получить его можно скопилив leak.c детали по первой же ссылке в статье. Вам блин всё готовое подавай смотрю. И так готовый эксплоит есть, так нет и воспользоваться не могут…
      • +2
        Почему именно «этот» (кстати этот — это какой?), если эксплуатируется не содержимое ключа, а сам факт его наличия? leak.c — это пример, который показывает, что референс каунтер утекает, и всё. Если написанные выше утверждения не верны (их я почерпнул прочитав исходники эксплоита), то расскажите как обстоят дела на самом деле.
        • –2
          Под рукой нет системы подходящей. Но подозреваю что нужно указывать один из этих ключей http://joxi.ru/bmoeOLTM7MwxAy
        • +1
          Всё верно говорите. Кто-то почитал исходник, а кто-то просто так советы дает.
  • 0
    Ну… таки опубликовали. Мою заметку поглотила лень.
  • +1
    В 4.3.3 (Arch Linux) уже закрыли дырку.

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