Компания Qualys раскрыла (https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt) результаты исследования, в рамках которого была изучена возможность эксплуатации уязвимостей, приводящих к пересечению содержимого стека и кучи. В частности, когда стек и куча размещаются смежно и прилегают друг к другу (область стека следует сразу за памятью, выделенную под кучу), то в условиях того, что куча растёт в сторону увеличения, а стек в сторону уменьшения не исключено возникновение ситуаций, когда содержимое переполненной кучи может оказаться в области стека или, наоборот, стек переписать область кучи.
Исследователи Qualys попытались выявить практические методы возникновения подобных столкновений, что им блестяще удалось - выявлено 20 уязвимостей, связанных с недоработками выделения памяти в стеке/куче ядра, libc и компонентов пространства пользователя, и позволяющих обойти средства защиты от выхода за границы стека (stack stack guard-page). Для демонстрации практических атак создано 15 рабочих прототипов эксплоитов, позволяющих повысить свои привилегии через манипуляции с различными приложениями в различных операционных системах.
Предложенные методы атаки разделены на три базовые категории:- Столкновение стека с другой областью памяти: выделение памяти производится до тех пор, пока стек не достигнет другой области памяти или пока другая область памяти не достигнет стека;
- Проброс мимо страницы защиты стека (stack guard-page): указатель стека перемещается из стека в другую область памяти, без доступа к странице защиты стека, которая генерирует page-fault;
- Разбиение стека или другой области памяти: осуществляется перезапись стека содержимым другой области памяти или перезапись другой области памяти содержимым стека. В качестве другой области памяти может выступать куча, анонимный mmap(), доступный на запись/чтение сегмент ld.so или PIE (Position-Independent Executable).
Среди опубликованных прототипов эксплоитов:
- Локальная root-уязвимость в Exim, манипулирующая недоработкой (CVE-2017-1000369 (https://security-tracker.debian.org/tracker/CVE-2017-1000369)), из-за которой при обработке некоторых аргументов командой строки не выполняется корректное освобождение памяти. Воспользовавшись данной проблемой локальный атакующий может в сочетании с уязвимостью CVE-2017-1000376 (https://security-tracker.debian.org/tracker/CVE-2017-1000376) в glibc организовать выполнение своего кода с правами root. Эксплоит протестирован в Debian GNU/Linux (i386);- Поднятие привилегий в системе через утилиту sudo. Для атаки используется сочетание уязвимостей в sudo (CVE-2017-1000367 (https://security-tracker.debian.org/tracker/CVE-2017-1000367)) и в Glibc (CCVE-2017-1000366 (https://security-tracker.debian.org/tracker/CVE-2017-1000366)). Проблема в Glibc вызвана некорректной обработкой памяти, выделенной для переменных окружения в suid-программах. Работа эксплоита продемонстрирована в Debian, Ubuntu и CentOS (i386);
- Ещё один эксплоит, позволяющий получить привилегии root через манипуляцию с утилитой sudo. Эксплоит примечателен работой в дистрибутивах с включенным SELinux;
- Локальный root-эксплоит через манипуляцию с ld.so и большинством SUID-root программ (используются уязвимости в glibc CVE-2017-1000366 (https://security-tracker.debian.org/tracker/CVE-2017-1000366) и ядре Linux CVE-2017-1000370 (https://security-tracker.debian.org/tracker/CVE-2017-1000370)). Работа эксплоита продемонстрирована в Debian, Fedora и CentOS (i386);
- Локальный root-эксплоит через манипуляцию с ld.so и большинством SUID-root программ, собранных в режиме PIE (используется уязвимость в glibc CVE-2017-1000366 (https://security-tracker.debian.org/tracker/CVE-2017-1000366) и другая уязвимость в ядре Linux CVE-2017-1000371 (https://security-tracker.debian.org/tracker/CVE-2017-1000371)). Работа эксплоита продемонстрирована в Debian, Fedora и Ubuntu (i386);
- Локальный root-эксплоит против утилиты /bin/su (используется уязвимость в glibc CVE-2017-1000366 (https://security-tracker.debian.org/tracker/CVE-2017-1000366) и уязвимость в ядре Linux CVE-2017-1000365 (https://security-tracker.debian.org/tracker/CVE-2017-1000365)). Работа эксплоита продемонстрирована в Debian (i386);- Концептуальный эксплоит для получения контроля за регистром eip через sudo на системах i386 с патчами grsecurity/PaX (CVE-2017-1000367 (https://security-tracker.debian.org/tracker/CVE-2017-1000367), CVE-2017-1000366 (https://security-tracker.debian.org/tracker/CVE-2017-1000366), CVE-2017-1000377 (https://security-tracker.debian.org/tracker/CVE-2017-1000377));
- Концептуальный эксплоит для получения контроля за указателем адреса возврата (rip) через манипуляции с Exim (CVE-2017-1000369 (https://security-tracker.debian.org/tracker/CVE-2017-1000369)) в окружении Debian (amd64);
- Локальный root-эксплоит против ld.so и большинство SUID-root приложений (CVE-2017-1000366 (https://security-tracker.debian.org/tracker/CVE-2017-1000366), CVE-2017-1000379 (https://security-tracker.debian.org/tracker/CVE-2017-1000379)). Работа эксплоита продемонстрирована в Debian, Ubuntu, Fedora и
CentOS (amd64);- Концептуальный эксплоит для обхода защиты stack guard-page в OpenBSD через манипуляции с утилитой /usr/bin/at. Для атаки используются уязвимости в реализации stack guard-page (CVE-2017-1000372 (https://security-tracker.debian.org/tracker/CVE-2017-1000372)) и libc функции qsort (CVE-2017-1000373 (https://security-tracker.debian.org/tracker/CVE-2017-1000373));
- Концептуальный эксплоит для обхода защиты stack guard-page в NetBSD (CVE-2017-1000374 (https://security-tracker.debian.org/tracker/CVE-2017-1000374), CVE-2017-1000375 (https://security-tracker.debian.org/tracker/CVE-2017-1000375));- Концептуальный эксплоит для атаки в окружении FreeBSD для обхода защиты RLIMIT_STACK в setrlimit (CVE-2017-1000385 (https://security-tracker.debian.org/tracker/CVE-2017-1000385));
- Для концептуальных эксплоита для обхода защиты stack guard-page во FreeBSD (CVE-2017-1083 (https://security-tracker.debian.org/tracker/CVE-2017-1000383), CVE-2017-1084 (https://security-tracker.debian.org/tracker/CVE-2017-1000384));
- Локальный root-эксплоит против /usr/bin/rsh в окружении Solaris 11 (CVE-2017-3630 (https://security-tracker.debian.org/tracker/CVE-2017-3630), CVE-2017-3629 (https://security-tracker.debian.org/tracker/CVE-2017-3629), CVE-2017-3631 CVE-2017-3631 (https://security-tracker.debian.org/tracker/)).
Для большинства вышеотмеченных уязвимостей уже доступны обновления от дистрибутивов (разработчики дистрибутивов были в закрытом порядке извещены о проблемах в середине мая и сегодня скоординировано выпустили обновления). В качестве общей меры для противодействия выявленным уязвимостям предлагается пересобрать все приложения и библиотеки в пространстве пользователя с использованием опции-fstack-check" в GCC, которая добавляет защиту от перемещения указателя стека в другую область памяти минуя stack guard-page. Для защиты в краткосрочной перспективе можно увеличить размер stack guard-page как минимум до 1 Мб и предоставить средства для произвольного изменения данного размера администратором (например, grsecurity/PaX предоставляет /proc/sys/vm/heap_stack_gap).
URL: http://openwall.com/lists/oss-security/2017/06/19/1
Новость: http://www.opennet.me/opennews/art.shtml?num=46724
А разве нельзя на уровне ОС выделять страницы памяти так, чтобы между соседними выделенными участками всегда находилась страница, при обращении к которой на чтение или запись, программа завершала бы работу?
Это и есть stack guard-page про обход которой говориться в новости.
> А разве нельзя на уровне ОС выделять страницы памяти так, чтобы между
> соседними выделенными участками всегда находилась страница, при обращении к которой на
> чтение или запись, программа завершала бы работу?В мире управляемых языков таких проблем нет.
> В мире управляемых языков таких проблем нет.Rust is 'memory safe' but has this same stack exhaustion issue.
Rust не управляемый язык. Речь идёт о C#.
> Rust не управляемый язык. Речь идёт о C#.http://cdn3.meme.am/cache/images/folder526/600x600/16784526/...
Вот только ОСей на этих управляемых языках нету.
И в ближайшем будущем не будет, ибо ядро должно быть производительным. Может быть появятся, если придумают соответствующую аппаратную поддержку со стороны процессоров.
Уже пытались... Толку нет
Неудачники, не хватает гения.
Стэка в упр коде вроде как по определению быть не может. Расплата в производительности.
Зато в виртуальных машинах таких языков ещё как есть.
Легче исправить в одной виртуальной машине, чем в миллионах проектов.
http://cdn3.meme.am/cache/images/folder526/600x600/16784526/...
> CCVE-2017-1000366Предложил мелкую правку новости с учётом https://cve.basealt.ru/informatsiia-ob-uiazvimosti-cve-2017-... ;-)
А что за механизм защиты?
> А что за механизм защиты?commit b7a528c6ce72ee0350c5f51f76d0986aba7706b2
Author: Dmitry V. Levin <ldv@altlinux.org>
Date: Mon Oct 20 11:06:36 2008 +0000owl-alt-sanitize-env
Sanitize the environment in a paranoid way.Этот код, существующий в alt-овской glibc с 2001 года (и несколько меняющийся со временем), спасал ALT от множества CVE, которые реализовывались через передачу SUID-ным программам какой-нибудь дряни через окружение. Вот и в этот раз -- у атакующего нет возможности напихать в ENV достаточно мусора, чтоб перепрыгнуть stack guard page.
> А что за механизм защиты?В дополнение к уже сказанному boyarsh@ цитирую ответ ldv@:
---
Наша официальная позиция была следующей:
"glibc: being maintainers and happy users of owl-alt-sanitize-env
hardening patch
http://git.altlinux.org/gears/g/glibc.git?p=glibc.git;a=comm...
that, in particular, makes LD_* and OUTPUT_CHARSET environment variables
unavailable in case of __libc_enable_secure, we don't see any necessity
to release a glibc update this time."См. тж. http://openwall.com/lists/oss-security/2017/06/19/8
---
> Предложил мелкую правку новости с учётом https://cve.basealt.ru/informatsiia-ob-uiazvimosti-cve-2017-...
> ;-)Как-то слишком голословно, что именно за защита?
PS. Главное то не упомянули, что основная дыра CVE-2017-100036 в ALT присутствует и ещё не исправлена https://cve.basealt.ru/informatsiia-ob-uiazvimosti-cve-2017-...
> Главное то не упомянули, что основная дыра CVE-2017-100036 в ALT присутствуетэто _не_ дыра.
Дыра - ошибка в коде программы, позволяющая, подсунув ей то, о чем не подумал автор, выполнить что-то непредусмотренное.
А этот CVE - просто доработка и без того крайне сомнительного и неэффективного механизма, который _иногда_, если погода летная, позволяет пользователям творения, написанного рукожопым программистом, не слишком дорого заплатить за эту рукожопость.(интересно, я правильно угадываю, что ценой +1 мегабайт к VSS _каждого_ запущенного в системе процесса? )
Вероятно, env sanitizing гораздо более разумная подстраховка на этот случай. Поскольку это именно то, что должнен был сделать, и не сделал, автор программы.
> Вероятно, env sanitizing гораздо более разумная подстраховка на этот случай. Поскольку
> это именно то, что должнен был сделать, и не сделал, автор
> программы.Если по уму, то это должны делать авторы libc, поскольку ld.so тоже использует переменные окружения, и в его коде уже находили и публиковали уязвимости. Лет 7 прошло, а воз и ныне там.
> Если по уму, то это должны делать авторы libcавтор либси - некто Ульрих Дрепер, известный своим клиническим вывихом мозгов. Очень смешно ожидать от него и его наследников интеграции этого патча десятилетней давности. А libc5, к сожалению, немного не стильно, модно и молодежно.
Кстати, и что мешает нормально написать ld.so (далеко не архисложная программа) я тоже не знаю.
Уже давно пилят без Дреппера.
> Очень смешно ожидать от него и его наследников интеграции этого патча десятилетней
> давности.Там сейчас сильно другая ситуация, но добиться консенсуса по чему-нить вроде http://sisyphus.ru/ru/srpm/Branch4/glibc/patches/31 (glibc-2.5-obsd-alt-strlcpy-strlcat.patch по состоянию на четвёртый альт, сейчас это где-то в гите) пока не получилось.
тут я не уверен, что оно a) вообще нужно в libc (любое добавление кода ломает совместимость) b) все чисто с лицензией. Проблема явно может быть решена вне libc, отдельной libopenbsdgoodfeature.sobtw, интересно, сложно ли сделать в ядре для suid-files аналог "link if owner match" - позволило бы перекрыть класс эксплойтов а-ля sudo (в которой и аналогичных бинарниках, по-моему, вообще имело бы смысл проверять собственное имячко, и сегфолтиться при любом его отличии от %PREFIX/sudo) - я вот не могу представить себе ситуации, когда легитимному пользователю понадобился бы линк на сетуиденый бинарь, хоть символический, хоть хард. (разьве что где-нибудь в треш-окрестностях user namespaces, но там пусть у их изобретателей голова болит)
> тут я не уверен, что оно a) вообще нужно в libc (любое
> добавление кода ломает совместимость) b) все чисто с лицензией. Проблема явно
> может быть решена вне libc, отдельной libopenbsdgoodfeature.soЕсли не в libc, то никак не в библиотеке, которая будет подгружаться уже после обработки части переменных окружения в раннем коде ld.so, где уже были уязвимости: http://seclists.org/fulldisclosure/2010/Oct/257
> btw, интересно, сложно ли сделать в ядре для suid-files аналог "link if
> owner match" - позволило бы перекрыть класс эксплойтов а-ля sudo (вfs.protected_hardlinks?
> fs.protected_hardlinks?эта фича, в том виде в котором была обнаружена в rhel, не проверяет su/gid биты (зато, зачем-то, write access) - и в таком виде, очевидно, небезвредная. В результате именно на системе с многими локальными пользователями рано или поздно тебе ее придется отключить.
с симлинками она вообще нечто непонятное делает (в смысле, непонятно, зачем такое нужно), совершенно не мешая сделать симлинк на sudo.
ненене, не надо нам такой уличной магии.
> Если не в libc, то никак не в библиотеке, которая будет подгружаться
> уже после обработки части переменных окружения в раннем коде ld.so, гдеэто мы уже о другой фиче, ld.so она перпендикулярна, просто новая функциональность в libc, с тем же успехом могущая жить в любой другой (и статически слинкованной в том числе).
А если ее воткнуть в libc - первая же использующая эту фичу программа станет несовместима со всеми старыми системами.
> уже были уязвимости: http://seclists.org/fulldisclosure/2010/Oct/257вот почему его до сих пор не переписали руками нормально - загадка, подумаешь, динамический линкер...
Это просто ужас какой-то
Я правильно понимаю что, стек можно определить двумя адресами - начало и конец.
Также и с кучей(наверное можно обойдись только началом?).
Почему нельзя просто проверять границы?
if((operation == new and Addr < HeapStartAddr) or
(operation == stack and StackStartAddr < Addr < StackEndAddr)
) cout << "Error";Там же неверняка накладные расходы на реализацию защищенной страницы не меньше?
Объясните, а то для моих скудных познаний stack guard-page выглядит слишком костыльно.
Конечно же код неправильный - границы стека и кучи меняются. При выделении памяти надо проверять, что не заходим за чужой диапазон. Но суть вопроса остается.
>>Там же неверняка накладные расходы на реализацию защищенной страницы не меньше?Этим вроде как менеджер памяти ОС должен заниматься. Поэтому меньше должно быть.
>>>Там же неверняка накладные расходы на реализацию защищенной страницы не меньше?
> Этим вроде как менеджер памяти ОС должен заниматься. Поэтому меньше должно быть.Оно по-любому меньше будет, потому как в первом случае проверка при каждой операции, а вот при использовании guard-page - только непосредственно при обращении к данному региону.
>>только непосредственно при обращении к данному региону."Обращение к региону" это выход push за пределы страницы? Пойду побью себя Таненбаум-ом по голове, освежу основы на всякий случай.
> "Обращение к региону" это выход push за пределы страницы?Ну да, а что?
Я толком правда уже не помню, но вроде как прилетает pagefault-эксепшн со стороны железа (x86) при попытке чтения, записи и т.д. без соответсвующего флажка страницы.
> Там же неверняка накладные расходы на реализацию защищенной страницы не меньше?
> Объясните, а то для моих скудных познаний stack guard-page выглядит слишком костыльно.http://wiki.osdev.org/Paging
Если вкратце, то проверки страниц проводятся так или иначе (причем, при каждом обращении программы к памяти -- взять ту же NX-фичу, которой уже лет эдак пятнадцать. Т.е. скорость проверки соответсвует потребностям) и "guard" - это просто-напросто страница памяти без каких либо разрешений.
PROT_NONE No permissions at all.
PROT_READ The pages can be read.
PROT_WRITE The pages can be written.
PROT_EXEC The pages can be executed
И кончено, оно наамного быстрее костылей с проверками при каждой операции.
Единственно, памяти "тратится" минимум PAGE_SIZE
getconf PAGE_SIZE
4096
и поэтому лепить для защиты стековых переменных/фрейма выходит вроде как все еще несколько накладно.
>[оверквотинг удален]
> PROT_EXEC
> The pages can be executed
Стоит уточнить, что «тратится» из-за сторожевых страниц не просто память, а именно виртуальная; в физическую память это страницы не отображаются, поэтому все накладные расходы связаны с поддержанием служебных таблиц виртуальной памяти (чем они больше, чем чаще ЦП при обращении к ним промахивается мимо кэша и тем дольше их простой перебор).
> Там же неверняка накладные расходы на реализацию защищенной страницы не меньше?Stack guard страница фактически не требует никаких накладных расходов, она один раз ядром помечается как недоступная для приложения, а потом процессор генерит исключение когда к ней происходит обращение. Процессор постоянно проверяет эти права, не только для охранной страницы, а для всех.
А вот указатель стека проверять -- это реально накладные расходы, потому что стек реально реализован через регистр rbp, который указывает на вершину стека, и приложение с ним может играть как угодно. Выделить память под новый стек из кучи и нацелить rbp туда, например. Есть даже готовые функции в libc для подобной игры с rbp: о них можно почитать в info libc 'Non-Local exits'.
Большая часть софта не делает этого, оставляя всю работу со стеком компилятору. Но даже там проверки указателя стека могут оказаться накладным удовольствием. Указатель стека меняется при каждом вызове функции, при каждой инструкции push/pop, при каждом объявлении локальной переменной в C... И при этом компилятор, в общем-то, не знает границ стека, об этом наверное только компоновщик узнаёт, тот которые объектные файлы в готовый бинарь собирает. А может быть даже и он не знает, а уже динамический компоновщик устанавливает эти границы, когда грузит бинарь в память процесса. Но с этими тонкостями я не разбирался.
rbp указывает на начало фрейма функции, на вершину стека указывает rsp
> rbp указывает на начало фрейма функции, на вершину стека указывает rspДа, спасибо за поправку.
У меня с -fstack-check localedef в glibc падает в сегфолт. Проверьте, так же у вас?
2.24
Известный баг
https://bugs.gentoo.org/show_bug.cgi?id=608788
https://sourceware.org/bugzilla/show_bug.cgi?id=21253
Благодарю, патчик самое то.
И эти же анонимы ржут по поводу Hurd. Ну ржите...
Ну, подход "давайте смиримся с кривым кодом и просто распихаем по песочницам" нравится не всем. Так как создаёт больно уж много тормозов и неудобств.
> И эти же анонимы ржут по поводу Hurd. Ну ржите...И где твой Hurd? Почему, если он такой безопасный, его до сих пор не внедрили, а взяли почему-то Linux.
Hurd не нужен корпорациям
А почему ?
А чем бы помог Hurd в большинстве указанных случаев? Ну кроме того, что он на той стадии развития, когда о защитах вроде stack guard-page еще не думают, а значит подобные эксплоиты это оверкилл.
Можно подумать, что с Hurd все эти проблемы в статье магическим образом решаются.
Там же микроядро ! Они магическим образом решает все проблемы.
В Linux, по историческим причинам, используется плоская модель памяти, т.е. код, данные, куча и стек находятся в едином адресном пространстве. Вся защита строится на ограничении доступа записи к отдельным страницам и рандомизации размещения.Куча и стек _должны_ быть доступны на запись. Регистр процессора "указатель на вершину стека" доступен на запись, это необходимо для организации фрейма локальных данных.
Достаточно установить стековый регистр или регистр начала фрейма на валидный адрес и "stack guard-page" ничем не поможет.
В системах с сегментной организацией памяти таких проблем нет.
> В Linux, по историческим причинам, используется плоская модель памяти, ...
> В системах с сегментной организацией памяти таких проблем нет.Не назовет ли автор действующие операционки с прогрессивной сегментной организацией? ;)
Последняя была в IBM z series.Но общую тенденцию озвучил главный:
Security people are often the black-and-white kind of people that I can't stand. I think the OpenBSD crowd is a bunch of masturbating monkeys, in that they make such a big deal about concentrating on security to the point where they pretty much admit that nothing else matters to them.
Torvalds, Linus (2008-07-15).
Ну так главный знает, что говорит. Потребности в безопасности - они у всех разные, начиная с полного отсутствия и заканчивая высями небесными. Поэтому первичным должно быть решение задач, а безопасность (с сопутствующими накладными расходами) - добавляться/убавляться по необходимости.
Правильно. Никакой магии, простой компромис.
Вот только в AMD64 от сегментации избавились, поспешно и неосмотрительно.
При переключении контекста задач, требуется подгрузить таблицу трансляции адресов для каждого сегмента. Это вызывает шоковую нагрузку на кэш процессора.В AMD64 шина адреса 48 бит, при этом, мнимальный размер страницы 4kB, т.е. отбрасываем 12 бит и получаем 2^36 записей в таблице трансляции. Это много, даже для иерархического представления MMU x86.
Избавились поспешно, но осмотрительно. ;)
> При переключении контекста задач, требуется подгрузить таблицу трансляции адресов для
> каждого сегмента.Нет, не требуется. Страничные таблицы никогда не подгружаются в кэш заранее целиком.
> Это вызывает шоковую нагрузку на кэш процессора.
Нет, не вызывает. Единственная "шоковая" нагрузка - это сброс TLB, который при переключении контекста (не режима) происходит в любом случае, будь там хоть один сегмент, хоть несколько.
> В AMD64 шина адреса 48 бит, при этом, мнимальный размер страницы 4kB,
> т.е. отбрасываем 12 бит и получаем 2^36 записей в таблице трансляции.
> Это много, даже для иерархического представления MMU x86.Это всё к делу совершенно не относится.
> Избавились поспешно, но осмотрительно. ;)
По совершенно другим причинам. Осмотрительно или не - спорить не вижу смысла.
>> Избавились поспешно, но осмотрительно. ;)
>По совершенно другим причинам.можно узнать по каким ? мне сильно не понятен этот вопрос и почему вообще отказались от сегментной модели памяти типа 486х ?
> можно узнать по каким ? мне сильно не понятен этот вопрос и
> почему вообще отказались от сегментной модели памяти типа 486х ?Моральное устаревание. На тот момент сегменты кода, данных и стека с разными адресами базы нигде как самостоятельные не использовались и считались, как и сейчас, пережитком прошлого.
>> можно узнать по каким ? мне сильно не понятен этот вопрос и
>> почему вообще отказались от сегментной модели памяти типа 486х ?
> Моральное устаревание. На тот момент сегменты кода, данных и стека с разными
> адресами базы нигде как самостоятельные не использовались и считались, как и
> сейчас, пережитком прошлого.и сейчас нет в современном процессоре механизма на запрет чтение/запись/исполнение в зависимости от сегмента кода/аналога ?
rhel5 x64 подвержен ?
> rhel5 x64 подвержен ?судя по приехавшему сегодня патчу ведра - да.
Патчей sudo, ld.so и всего прочего - вероятно, не дождетесь. А патч ведра защищает только от poc-эксплойтов квалиса, и то если повезло, а не от любых других.
интересно, а сентос обновит или забьет ?
> интересно, а сентос обновит или забьет ?а они разьве поддерживают пятую версию?
Нужно реализовать аппаратную поддержку маркировки страниц как стек и куча с проверкой процессором, что адресации относительно rsp идут на страницу со стеком, а остальные - на страницы с кучей.
