Комментарии 26
Я так понимаю, чтобы воспользоваться этой дыркой — надо вынудить пользователя запустить некий бинарник?
Тоесть уязвимость по сути касается «прокладки меж экраном и креслом»?
Тоесть уязвимость по сути касается «прокладки меж экраном и креслом»?
Я бы, на самом деле, не исключал вероятности атаки, которая опосредованно приведёт к stack clash, например, на JavaScript интерпретатор в браузере,
SSH на виртуальном хостинге, не?
Нет, опасность в том, что злоумышленник может получить доступ к пользовательскому аккаунту, а потом повысить уровень привилегий до суперпользователя. Например, недавняя уязвимость в самбе позволяла выполнить сторонний код, но выполнялся он с привилегиями самбы, то есть, почти никакими, поэтому уязвимость была не особо серьёзной. Но если выполнять код из этой статьи, то всё становится куда опаснее.
Офигеть, 12 лет! 12 лет, Карл!
Я в шоке!
Я в шоке!
НЛО прилетело и опубликовало эту надпись здесь
GrSecurity с этой уязвимостью вероятнее всего справится.
НЛО прилетело и опубликовало эту надпись здесь
Справедливости ради стоит отметить, что Линуксу до величины меры решетовости MS Windows 3/3.1195/98/XP/7/8/10/NT — еще очень далеко.
Я бы оценил меру решетовости Линукса как 0,00023 от MS Windows.
Я бы оценил меру решетовости Линукса как 0,00023 от MS Windows.
Просто когда пишут о проблемах в мире Linux, пишут О БОЖЕ ВЗЛОМ ХАКЕРЫ УЯЗВИМОСТЬ ВСЕ УКРАДУТ.
В реальности баг на самбе едва ли можно было эксплуатировать (почти ни у кого сервис не работает, а у кого работает — только с правами самбы, то есть вообще почти никакими).
Насчет этого бага — во-первых, как его удаленно воспроизвести? Во-вторых, «при смежном размещении стека и кучи не исключены ситуации, когда содержимое переполненной кучи может оказаться в области стека, или стек, наоборот <...>». То есть этого всего нужно еще и добиться.
В общем, на серьезную прям дыру это не похоже, хотя исправлять, конечно, надо.
В реальности баг на самбе едва ли можно было эксплуатировать (почти ни у кого сервис не работает, а у кого работает — только с правами самбы, то есть вообще почти никакими).
Насчет этого бага — во-первых, как его удаленно воспроизвести? Во-вторых, «при смежном размещении стека и кучи не исключены ситуации, когда содержимое переполненной кучи может оказаться в области стека, или стек, наоборот <...>». То есть этого всего нужно еще и добиться.
В общем, на серьезную прям дыру это не похоже, хотя исправлять, конечно, надо.
Я думаю что те у кого есть самба, ну например организация где я работаю, на этой самой самбе держат вещи важные. Например у меня там личные папки рабочих мест на 30 сотрудников, и пострадавшая самба, убившая все данные — потеря-потерь.
Для того, чтобы выполнить сторонний код в дыре Samba на Linux, нужно иметь открытую папку на запись. Если важные личные папки сотрудников лежат в открытых доступе на чтение/запись, хоть на самбе, хоть на фтп, хоть еще где — это в любом случае плохо.
Если же доки лежат в закрытых на запись папках, а какая-нибудь одна папка upload открыта на запись, то залитый туда эксплоит позволит лишь выполнить код с правами Samba. То есть никакие документы пользователя и прочее она не сможет удалить.
Все это может произойти, только если у вас проблемы с админом. На все 777, доступ везде, максимальные права. Но это, ё моё, надо постараться еще и вообще не понимать, что делаешь.
Если же доки лежат в закрытых на запись папках, а какая-нибудь одна папка upload открыта на запись, то залитый туда эксплоит позволит лишь выполнить код с правами Samba. То есть никакие документы пользователя и прочее она не сможет удалить.
Все это может произойти, только если у вас проблемы с админом. На все 777, доступ везде, максимальные права. Но это, ё моё, надо постараться еще и вообще не понимать, что делаешь.
Ну смотрите: Есть сервер где каждому юзверю дается своя папка, которая монтируется виндою как сетевой ЖД. Ограничения — запись доступна только для него. Он туда может записать хоть что. При записи туда файлика нужного — крякнет вся самба, со всеми папками. Я не прав?
Второй вариант — у нас есть файлообмен, где лежит почти 200 гигов всякого хлама который пользователи перекидывают друг-другу. Так как секретного ничего нет, это все лежит в одной директории 777. Тоже под угрозой находится?
Второй вариант — у нас есть файлообмен, где лежит почти 200 гигов всякого хлама который пользователи перекидывают друг-другу. Так как секретного ничего нет, это все лежит в одной директории 777. Тоже под угрозой находится?
1) Зависит от прав, при котором запущен сервис Samba. Если прав нет (что правильно), то кроме папки с правами на запись ничего не умрет.
2) Да, под угрозой.
2) Да, под угрозой.
Да? А если теперь творчески объединить эти два эксплоита? И потом, много там было из 99.99977% уязвимостей именно в такой фундаментальной вещи, как ядро и работа с памятью? И воспроизводились ли эти уязвимости, которые работали во времена ХР на 10? А ведь это тот самый пресловутый опенсорс.
Что объединять-то? Самба на 99.9% линуховых машинах вообще не включена. Комментом выше я ответил, что даже включив ее, нужно очень постараться, чтобы сделать из нее уязвимость, которую можно эффективно эксплуатировать.
А данный эксплоит можно воспроизвести только при физическом доступе в компу. Удаленный запуск возможен лишь теоретически: например, нааллоцировать тонны памяти в браузере и заставить записанный код с нужной привилегией выполняться. Сомнительно, что это можно провести. Во всяком случае, у меня не получилось, как и у ребят из статьи.
А при физическом доступе к компу вообще может быть много проблем, в том числе и приделанные к его системнику или харду ноги, мало зависящие от IT.
А данный эксплоит можно воспроизвести только при физическом доступе в компу. Удаленный запуск возможен лишь теоретически: например, нааллоцировать тонны памяти в браузере и заставить записанный код с нужной привилегией выполняться. Сомнительно, что это можно провести. Во всяком случае, у меня не получилось, как и у ребят из статьи.
А при физическом доступе к компу вообще может быть много проблем, в том числе и приделанные к его системнику или харду ноги, мало зависящие от IT.
>> Для использования описанной проблемы безопасности необходим локальный доступ к компьютеру
Веб шелла будет достаточно.
>> однако специалисты не исключают наличия возможности удаленной эксплуатации, например, посредством HTTP-запросов или JavaScript.
Это тоже протестируем, естественно в исследовательских целях.
Веб шелла будет достаточно.
>> однако специалисты не исключают наличия возможности удаленной эксплуатации, например, посредством HTTP-запросов или JavaScript.
Это тоже протестируем, естественно в исследовательских целях.
Не очень понятно, как из пересечения кучи и стека обычного процесса повысить привилегии, ядро сходит с ума? Кто-нибудь в курсе?
Прочитал доку от 2005 года, не нашел там ответа, похоже действительно сценарий такой, заставить браузер алоцировать много памяти, записать туда что-то и заставить выполниться.
Изменить стек процесса в момент, когда выполняется процесс с высокими привилегиями, например sudo. И дальше — запустить из него shell с теми же высокими привилегиями.
Аналогия для Windows. В своей время Dr.Web, запущенный с правами админа, под самым обычным пользователем показывал справку через окно IE, Но окно IE — это почти проводник, и из этой справки можно было запустить обычный проводник или Far. Естественно в режиме администратора.
Аналогия для Windows. В своей время Dr.Web, запущенный с правами админа, под самым обычным пользователем показывал справку через окно IE, Но окно IE — это почти проводник, и из этой справки можно было запустить обычный проводник или Far. Естественно в режиме администратора.
Ну, вообще-то, если вспомнить про разделение адресных пространств процессов, то изменение стека одного из процессов, никак не влияет на другие…
Другое дело, что из пользовательского процесса можно обратиться к процессу, исполняемому в режиме ядра, к примеру sudo, и, с помощью данной уязвимости, «свести его с ума», получив, таким образом, повышенные привилегии.
Другое дело, что из пользовательского процесса можно обратиться к процессу, исполняемому в режиме ядра, к примеру sudo, и, с помощью данной уязвимости, «свести его с ума», получив, таким образом, повышенные привилегии.
Тоже сначала не понял, пока не прочитал оригинал. Оказалось, что в процессе работы над уязвимостью, исследователи откопали еще несколько уязвимостей, напрямую связанных с первой:
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).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Уязвимость Stack Clash позволяет получить root-привилегии в Linux и других ОС