Уязвимость Stack Clash позволяет получить root-привилегии в Linux и других ОС



    Изображение:finnsland, CC BY-SA 2.0

    В механизме управления памятью операционных систем Linux, OpenBSD, NetBSD, FreeBSD и Solaris обнаружена серьезная уязвимость, позволяющая осуществлять повышение привилегий до уровня суперпользователя и выполнять произвольный код. Проблема безопасности получила название Stack Clash.

    В чем проблема


    Проблему обнаружили исследователи информационной безопасности из компании Qualys. Уязвимость была впервые обнаружена в 2005 году, тогда же появилось исправление. Однако в 2010 году исследователи выяснили, что выпущенные патчи не полностью блокируют возможность эксплуатации. Разработчики Linux вновь выпустили патч, однако оказалось, что защиту можно обойти.

    Суть уязвимости заключается в том, что при смежном размещении стека и кучи не исключены ситуации, когда содержимое переполненной кучи может оказаться в области стека, или стек, наоборот, может переписать область кучи, если куча растет в сторону увеличения, а стек — в сторону уменьшения. Для предотвращения подобных ситуаций в Linux и других операционных системах используется защитная техника stack guard-page.

    В ходе исследования эксперты выявили множественные уязвимости в реализации «сторожевой страницы» (guard-page) и выделили три возможных типа атак:

    • Пересечение стека с другой областью памяти: выделение памяти производится до тех пор, пока стек не достигнет другой области памяти или память не достигнет стека;
    • «Прыжок» через сторожевую страницу: в этом случае указатель стека перемещается из стека в другую область памяти не затрагивая страницу защиты памяти;
    • Разбиение стека или другой области памяти: производится перезапись стека содержимым другой области памяти либо другой области памяти содержимым стека.

    Исследователи подготовили набор PoC-эксплоитов для различных операционных систем. Для использования описанной проблемы безопасности необходим локальный доступ к компьютеру, однако специалисты не исключают наличия возможности удаленной эксплуатации, например, посредством HTTP-запросов или JavaScript.

    Как защититься


    Как сказано в отчете исследователей, они заранее оповестили разработчиков уязвимых операционных систем о найденных проблемах. В настоящий момент разрабатываются патчи, закрывающие уязвимость. Компания Red Hat уже опубликовала бюллетень безопасности — однако описанные в нем способы защиты могут негативно сказываться на производительности системы. Эту проблему разработчики обещают устранить позднее.

    По словам исследователей, они проверяли наличие проблемы в операционных системах FreeBSD, NetBSD, OpenBSD, Solaris, а также популярных Linux-дистрибутивов Red Hat, SuSE, Debian и Ubuntu. Пользователям рекомендуется проверить наличие обновлений для своего дистрибутива. На данный момент неясно, подвержена ли уязвимости мобильная ОС Android.

    В качестве временной меры до выхода патча для конкретной ОС ее пользователи могут изменить настройки опций RLIMIT_STACK и RLIMIT_AS для локальных учетных записей и удаленных сервисов, понизив значения по-умолчанию. Однако этот способ не позволит полностью обезопасить себя — выбор слишком низких значений не позволит работать многим доверенным приложениям, а выбор средней величины позволить осуществить ряд атак (например, Stack Clash атаку на Sudo).
    Positive Technologies
    150.19
    Company
    Share post

    Comments 26

      –3
      Я так понимаю, чтобы воспользоваться этой дыркой — надо вынудить пользователя запустить некий бинарник?
      Тоесть уязвимость по сути касается «прокладки меж экраном и креслом»?
        +1
        Я бы, на самом деле, не исключал вероятности атаки, которая опосредованно приведёт к stack clash, например, на JavaScript интерпретатор в браузере,
          +3
          SSH на виртуальном хостинге, не?
            +4

            Нет, опасность в том, что злоумышленник может получить доступ к пользовательскому аккаунту, а потом повысить уровень привилегий до суперпользователя. Например, недавняя уязвимость в самбе позволяла выполнить сторонний код, но выполнялся он с привилегиями самбы, то есть, почти никакими, поэтому уязвимость была не особо серьёзной. Но если выполнять код из этой статьи, то всё становится куда опаснее.

            +1
            Офигеть, 12 лет! 12 лет, Карл!
            Я в шоке!
            • UFO just landed and posted this here
                0
                GrSecurity с этой уязвимостью вероятнее всего справится.
                  +3

                  Это не волшебная пилюля:


                  Концептуальный эксплоит для получения контроля за регистром eip через sudo на системах i386 с патчами grsecurity/PaX (CVE-2017-1000367, CVE-2017-1000366, CVE-2017-1000377
                • UFO just landed and posted this here
                    –5
                    Справедливости ради стоит отметить, что Линуксу до величины меры решетовости MS Windows 3/3.1195/98/XP/7/8/10/NT — еще очень далеко.
                    Я бы оценил меру решетовости Линукса как 0,00023 от MS Windows.
                      –4
                      Просто когда пишут о проблемах в мире Linux, пишут О БОЖЕ ВЗЛОМ ХАКЕРЫ УЯЗВИМОСТЬ ВСЕ УКРАДУТ.

                      В реальности баг на самбе едва ли можно было эксплуатировать (почти ни у кого сервис не работает, а у кого работает — только с правами самбы, то есть вообще почти никакими).
                      Насчет этого бага — во-первых, как его удаленно воспроизвести? Во-вторых, «при смежном размещении стека и кучи не исключены ситуации, когда содержимое переполненной кучи может оказаться в области стека, или стек, наоборот <...>». То есть этого всего нужно еще и добиться.

                      В общем, на серьезную прям дыру это не похоже, хотя исправлять, конечно, надо.
                        0
                        Я думаю что те у кого есть самба, ну например организация где я работаю, на этой самой самбе держат вещи важные. Например у меня там личные папки рабочих мест на 30 сотрудников, и пострадавшая самба, убившая все данные — потеря-потерь.
                          –1
                          Для того, чтобы выполнить сторонний код в дыре Samba на Linux, нужно иметь открытую папку на запись. Если важные личные папки сотрудников лежат в открытых доступе на чтение/запись, хоть на самбе, хоть на фтп, хоть еще где — это в любом случае плохо.

                          Если же доки лежат в закрытых на запись папках, а какая-нибудь одна папка upload открыта на запись, то залитый туда эксплоит позволит лишь выполнить код с правами Samba. То есть никакие документы пользователя и прочее она не сможет удалить.

                          Все это может произойти, только если у вас проблемы с админом. На все 777, доступ везде, максимальные права. Но это, ё моё, надо постараться еще и вообще не понимать, что делаешь.
                            0
                            Ну смотрите: Есть сервер где каждому юзверю дается своя папка, которая монтируется виндою как сетевой ЖД. Ограничения — запись доступна только для него. Он туда может записать хоть что. При записи туда файлика нужного — крякнет вся самба, со всеми папками. Я не прав?

                            Второй вариант — у нас есть файлообмен, где лежит почти 200 гигов всякого хлама который пользователи перекидывают друг-другу. Так как секретного ничего нет, это все лежит в одной директории 777. Тоже под угрозой находится?
                              0
                              1) Зависит от прав, при котором запущен сервис Samba. Если прав нет (что правильно), то кроме папки с правами на запись ничего не умрет.

                              2) Да, под угрозой.
                                0
                                1) Если мы получили доступ до пользователя «самба» — то мы ставим под угрозу все папки всех пользователей, даже за паролем, ибо сервис имеет доступ до папок которые он шарит. Я не прав?
                                  0
                                  Если они под записей, то да. Мы можем шарить самбой файлы в том числе и только для чтения, поэтому получив права самбы, у нас не будет прав потереть эти файлы.
                          0
                          Да? А если теперь творчески объединить эти два эксплоита? И потом, много там было из 99.99977% уязвимостей именно в такой фундаментальной вещи, как ядро и работа с памятью? И воспроизводились ли эти уязвимости, которые работали во времена ХР на 10? А ведь это тот самый пресловутый опенсорс.
                            –1
                            Что объединять-то? Самба на 99.9% линуховых машинах вообще не включена. Комментом выше я ответил, что даже включив ее, нужно очень постараться, чтобы сделать из нее уязвимость, которую можно эффективно эксплуатировать.

                            А данный эксплоит можно воспроизвести только при физическом доступе в компу. Удаленный запуск возможен лишь теоретически: например, нааллоцировать тонны памяти в браузере и заставить записанный код с нужной привилегией выполняться. Сомнительно, что это можно провести. Во всяком случае, у меня не получилось, как и у ребят из статьи.
                            А при физическом доступе к компу вообще может быть много проблем, в том числе и приделанные к его системнику или харду ноги, мало зависящие от IT.
                        0
                        >> Для использования описанной проблемы безопасности необходим локальный доступ к компьютеру
                        Веб шелла будет достаточно.

                        >> однако специалисты не исключают наличия возможности удаленной эксплуатации, например, посредством HTTP-запросов или JavaScript.
                        Это тоже протестируем, естественно в исследовательских целях.
                          +2
                          Не очень понятно, как из пересечения кучи и стека обычного процесса повысить привилегии, ядро сходит с ума? Кто-нибудь в курсе?
                            0
                            Прочитал доку от 2005 года, не нашел там ответа, похоже действительно сценарий такой, заставить браузер алоцировать много памяти, записать туда что-то и заставить выполниться.
                              +2
                              Изменить стек процесса в момент, когда выполняется процесс с высокими привилегиями, например sudo. И дальше — запустить из него shell с теми же высокими привилегиями.

                              Аналогия для Windows. В своей время Dr.Web, запущенный с правами админа, под самым обычным пользователем показывал справку через окно IE, Но окно IE — это почти проводник, и из этой справки можно было запустить обычный проводник или Far. Естественно в режиме администратора.
                                +1
                                Ну, вообще-то, если вспомнить про разделение адресных пространств процессов, то изменение стека одного из процессов, никак не влияет на другие…
                                Другое дело, что из пользовательского процесса можно обратиться к процессу, исполняемому в режиме ядра, к примеру sudo, и, с помощью данной уязвимости, «свести его с ума», получив, таким образом, повышенные привилегии.
                                  0
                                  Родительский процесс может получить права на изменение памяти дочернего.

                                  В режиме ядра некоторое время исполняется любой процесс — во время системных вызовов обычно идет переход в режим ядра.
                                +1
                                Тоже сначала не понял, пока не прочитал оригинал. Оказалось, что в процессе работы над уязвимостью, исследователи откопали еще несколько уязвимостей, напрямую связанных с первой:
                                Our primary Stack Clash vulnerability is CVE-2017-1000364 and demonstrates that a stack guard-page of a few kilobytes is insufficient. But during our research we discovered more vulnerabilities: some are secondary and directly related to the primary Stack Clash vulnerability (for example,CVE-2017-1000365), and some are exploitable independently (for example, CVE-2017-1000367).

                              Only users with full accounts can post comments. Log in, please.