Изображение: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).
Комментарии (26)
KonstantinSpb
20.06.2017 20:53GrSecurity с этой уязвимостью вероятнее всего справится.
kay
21.06.2017 07:34+3Это не волшебная пилюля:
Концептуальный эксплоит для получения контроля за регистром eip через sudo на системах i386 с патчами grsecurity/PaX (CVE-2017-1000367, CVE-2017-1000366, CVE-2017-1000377
Alexeyco
20.06.2017 21:43+7И что, никто не осмелится? Ну ладно, тогда я…
Решето…
aristarh1970
21.06.2017 00:07-5Справедливости ради стоит отметить, что Линуксу до величины меры решетовости MS Windows 3/3.1195/98/XP/7/8/10/NT — еще очень далеко.
Я бы оценил меру решетовости Линукса как 0,00023 от MS Windows.
oYASo
21.06.2017 02:27-4Просто когда пишут о проблемах в мире Linux, пишут О БОЖЕ ВЗЛОМ ХАКЕРЫ УЯЗВИМОСТЬ ВСЕ УКРАДУТ.
В реальности баг на самбе едва ли можно было эксплуатировать (почти ни у кого сервис не работает, а у кого работает — только с правами самбы, то есть вообще почти никакими).
Насчет этого бага — во-первых, как его удаленно воспроизвести? Во-вторых, «при смежном размещении стека и кучи не исключены ситуации, когда содержимое переполненной кучи может оказаться в области стека, или стек, наоборот <...>». То есть этого всего нужно еще и добиться.
В общем, на серьезную прям дыру это не похоже, хотя исправлять, конечно, надо.
daggert
21.06.2017 17:01Я думаю что те у кого есть самба, ну например организация где я работаю, на этой самой самбе держат вещи важные. Например у меня там личные папки рабочих мест на 30 сотрудников, и пострадавшая самба, убившая все данные — потеря-потерь.
oYASo
22.06.2017 02:32-1Для того, чтобы выполнить сторонний код в дыре Samba на Linux, нужно иметь открытую папку на запись. Если важные личные папки сотрудников лежат в открытых доступе на чтение/запись, хоть на самбе, хоть на фтп, хоть еще где — это в любом случае плохо.
Если же доки лежат в закрытых на запись папках, а какая-нибудь одна папка upload открыта на запись, то залитый туда эксплоит позволит лишь выполнить код с правами Samba. То есть никакие документы пользователя и прочее она не сможет удалить.
Все это может произойти, только если у вас проблемы с админом. На все 777, доступ везде, максимальные права. Но это, ё моё, надо постараться еще и вообще не понимать, что делаешь.daggert
22.06.2017 13:05Ну смотрите: Есть сервер где каждому юзверю дается своя папка, которая монтируется виндою как сетевой ЖД. Ограничения — запись доступна только для него. Он туда может записать хоть что. При записи туда файлика нужного — крякнет вся самба, со всеми папками. Я не прав?
Второй вариант — у нас есть файлообмен, где лежит почти 200 гигов всякого хлама который пользователи перекидывают друг-другу. Так как секретного ничего нет, это все лежит в одной директории 777. Тоже под угрозой находится?oYASo
23.06.2017 00:261) Зависит от прав, при котором запущен сервис Samba. Если прав нет (что правильно), то кроме папки с правами на запись ничего не умрет.
2) Да, под угрозой.daggert
23.06.2017 00:511) Если мы получили доступ до пользователя «самба» — то мы ставим под угрозу все папки всех пользователей, даже за паролем, ибо сервис имеет доступ до папок которые он шарит. Я не прав?
oYASo
24.06.2017 15:01Если они под записей, то да. Мы можем шарить самбой файлы в том числе и только для чтения, поэтому получив права самбы, у нас не будет прав потереть эти файлы.
Namynnuz
21.06.2017 20:19Да? А если теперь творчески объединить эти два эксплоита? И потом, много там было из 99.99977% уязвимостей именно в такой фундаментальной вещи, как ядро и работа с памятью? И воспроизводились ли эти уязвимости, которые работали во времена ХР на 10? А ведь это тот самый пресловутый опенсорс.
oYASo
22.06.2017 03:01-1Что объединять-то? Самба на 99.9% линуховых машинах вообще не включена. Комментом выше я ответил, что даже включив ее, нужно очень постараться, чтобы сделать из нее уязвимость, которую можно эффективно эксплуатировать.
А данный эксплоит можно воспроизвести только при физическом доступе в компу. Удаленный запуск возможен лишь теоретически: например, нааллоцировать тонны памяти в браузере и заставить записанный код с нужной привилегией выполняться. Сомнительно, что это можно провести. Во всяком случае, у меня не получилось, как и у ребят из статьи.
А при физическом доступе к компу вообще может быть много проблем, в том числе и приделанные к его системнику или харду ноги, мало зависящие от IT.
r85qPZ1d3y
20.06.2017 22:31>> Для использования описанной проблемы безопасности необходим локальный доступ к компьютеру
Веб шелла будет достаточно.
>> однако специалисты не исключают наличия возможности удаленной эксплуатации, например, посредством HTTP-запросов или JavaScript.
Это тоже протестируем, естественно в исследовательских целях.
mikhailm1
20.06.2017 22:42+2Не очень понятно, как из пересечения кучи и стека обычного процесса повысить привилегии, ядро сходит с ума? Кто-нибудь в курсе?
mikhailm1
20.06.2017 22:48Прочитал доку от 2005 года, не нашел там ответа, похоже действительно сценарий такой, заставить браузер алоцировать много памяти, записать туда что-то и заставить выполниться.
Jef239
21.06.2017 00:33+2Изменить стек процесса в момент, когда выполняется процесс с высокими привилегиями, например sudo. И дальше — запустить из него shell с теми же высокими привилегиями.
Аналогия для Windows. В своей время Dr.Web, запущенный с правами админа, под самым обычным пользователем показывал справку через окно IE, Но окно IE — это почти проводник, и из этой справки можно было запустить обычный проводник или Far. Естественно в режиме администратора.
iChaos
21.06.2017 10:09+1Ну, вообще-то, если вспомнить про разделение адресных пространств процессов, то изменение стека одного из процессов, никак не влияет на другие…
Другое дело, что из пользовательского процесса можно обратиться к процессу, исполняемому в режиме ядра, к примеру sudo, и, с помощью данной уязвимости, «свести его с ума», получив, таким образом, повышенные привилегии.Jef239
21.06.2017 15:43Родительский процесс может получить права на изменение памяти дочернего.
В режиме ядра некоторое время исполняется любой процесс — во время системных вызовов обычно идет переход в режим ядра.
iChaos
21.06.2017 09:54+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).
Fox_exe
Я так понимаю, чтобы воспользоваться этой дыркой — надо вынудить пользователя запустить некий бинарник?
Тоесть уязвимость по сути касается «прокладки меж экраном и креслом»?
oldschoolgeek
Я бы, на самом деле, не исключал вероятности атаки, которая опосредованно приведёт к stack clash, например, на JavaScript интерпретатор в браузере,
osipov_dv
SSH на виртуальном хостинге, не?
avost
Нет, опасность в том, что злоумышленник может получить доступ к пользовательскому аккаунту, а потом повысить уровень привилегий до суперпользователя. Например, недавняя уязвимость в самбе позволяла выполнить сторонний код, но выполнялся он с привилегиями самбы, то есть, почти никакими, поэтому уязвимость была не особо серьёзной. Но если выполнять код из этой статьи, то всё становится куда опаснее.