| 1.3, Аноним (-), 21:54, 19/06/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А разве нельзя на уровне ОС выделять страницы памяти так, чтобы между соседними выделенными участками всегда находилась страница, при обращении к которой на чтение или запись, программа завершала бы работу?
| | |
| |
| 2.5, Аноним (-), 21:56, 19/06/2017 [^] [^^] [^^^] [ответить]
| +15 +/– |
Это и есть stack guard-page про обход которой говориться в новости.
| | |
| 2.6, Аноним (-), 21:56, 19/06/2017 [^] [^^] [^^^] [ответить]
| –15 +/– |
> А разве нельзя на уровне ОС выделять страницы памяти так, чтобы между
> соседними выделенными участками всегда находилась страница, при обращении к которой на
> чтение или запись, программа завершала бы работу?
В мире управляемых языков таких проблем нет.
| | |
| |
| 3.10, Michael Shigorin (ok), 22:31, 19/06/2017 [^] [^^] [^^^] [ответить]
| +5 +/– |
 > В мире управляемых языков таких проблем нет.
Rust is 'memory safe' but has this same stack exhaustion issue.
| | |
| |
| 4.24, Аноним (-), 23:43, 19/06/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
И в ближайшем будущем не будет, ибо ядро должно быть производительным. Может быть появятся, если придумают соответствующую аппаратную поддержку со стороны процессоров.
| | |
|
| 3.14, 123 (??), 22:41, 19/06/2017 [^] [^^] [^^^] [ответить]
| +/– |
Стэка в упр коде вроде как по определению быть не может. Расплата в производительности.
| | |
| |
| 4.47, Аноним (-), 11:51, 20/06/2017 [^] [^^] [^^^] [ответить]
| +/– |
Легче исправить в одной виртуальной машине, чем в миллионах проектов.
| | |
|
|
|
| |
| |
| 3.42, boyarsh (ok), 10:24, 20/06/2017 [^] [^^] [^^^] [ответить]
| +5 +/– |
 > А что за механизм защиты?
commit b7a528c6ce72ee0350c5f51f76d0986aba7706b2
Author: Dmitry V. Levin <ldv@altlinux.org>
Date: Mon Oct 20 11:06:36 2008 +0000
owl-alt-sanitize-env
Sanitize the environment in a paranoid way.
Этот код, существующий в alt-овской glibc с 2001 года (и несколько меняющийся со временем), спасал ALT от множества CVE, которые реализовывались через передачу SUID-ным программам какой-нибудь дряни через окружение. Вот и в этот раз -- у атакующего нет возможности напихать в ENV достаточно мусора, чтоб перепрыгнуть stack guard page.
| | |
|
| |
| 3.53, пох (?), 14:25, 20/06/2017 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Главное то не упомянули, что основная дыра CVE-2017-100036 в ALT присутствует
это _не_ дыра.
Дыра - ошибка в коде программы, позволяющая, подсунув ей то, о чем не подумал автор, выполнить что-то непредусмотренное.
А этот CVE - просто доработка и без того крайне сомнительного и неэффективного механизма, который _иногда_, если погода летная, позволяет пользователям творения, написанного рукожопым программистом, не слишком дорого заплатить за эту рукожопость.
(интересно, я правильно угадываю, что ценой +1 мегабайт к VSS _каждого_ запущенного в системе процесса? )
Вероятно, env sanitizing гораздо более разумная подстраховка на этот случай. Поскольку это именно то, что должнен был сделать, и не сделал, автор программы.
| | |
| |
| 4.55, добрый (?), 14:42, 20/06/2017 [^] [^^] [^^^] [ответить]
| +/– |
> Вероятно, env sanitizing гораздо более разумная подстраховка на этот случай. Поскольку
> это именно то, что должнен был сделать, и не сделал, автор
> программы.
Если по уму, то это должны делать авторы libc, поскольку ld.so тоже использует переменные окружения, и в его коде уже находили и публиковали уязвимости. Лет 7 прошло, а воз и ныне там.
| | |
| |
| 5.57, пох (?), 15:23, 20/06/2017 [^] [^^] [^^^] [ответить]
| +/– | |
> Если по уму, то это должны делать авторы libc
автор либси - некто Ульрих Дрепер, известный своим клиническим вывихом мозгов. Очень смешно ожидать от него и его наследников интеграции этого патча десятилетней давности. А libc5, к сожалению, немного не стильно, модно и молодежно.
Кстати, и что мешает нормально написать ld.so (далеко не архисложная программа) я тоже не знаю.
| | |
| |
| |
| 7.64, пох (?), 16:36, 20/06/2017 [^] [^^] [^^^] [ответить]
| +/– | |
тут я не уверен, что оно a) вообще нужно в libc (любое добавление кода ломает совместимость) b) все чисто с лицензией. Проблема явно может быть решена вне libc, отдельной libopenbsdgoodfeature.so
btw, интересно, сложно ли сделать в ядре для suid-files аналог "link if owner match" - позволило бы перекрыть класс эксплойтов а-ля sudo (в которой и аналогичных бинарниках, по-моему, вообще имело бы смысл проверять собственное имячко, и сегфолтиться при любом его отличии от %PREFIX/sudo) - я вот не могу представить себе ситуации, когда легитимному пользователю понадобился бы линк на сетуиденый бинарь, хоть символический, хоть хард. (разьве что где-нибудь в треш-окрестностях user namespaces, но там пусть у их изобретателей голова болит)
| | |
| |
| 8.66, добрый (?), 17:16, 20/06/2017 [^] [^^] [^^^] [ответить] | +/– | Если не в libc, то никак не в библиотеке, которая будет подгружаться уже после о... текст свёрнут, показать | | |
| |
| 9.67, пох (?), 17:42, 20/06/2017 [^] [^^] [^^^] [ответить] | +/– | эта фича, в том виде в котором была обнаружена в rhel, не проверяет su gid биты ... текст свёрнут, показать | | |
| 9.68, пох (?), 17:50, 20/06/2017 [^] [^^] [^^^] [ответить] | +/– | это мы уже о другой фиче, ld so она перпендикулярна, просто новая функциональнос... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
| 1.13, key (??), 22:41, 19/06/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Я правильно понимаю что, стек можно определить двумя адресами - начало и конец.
Также и с кучей(наверное можно обойдись только началом?).
Почему нельзя просто проверять границы?
if((operation == new and Addr < HeapStartAddr) or
(operation == stack and StackStartAddr < Addr < StackEndAddr)
) cout << "Error";
Там же неверняка накладные расходы на реализацию защищенной страницы не меньше?
Объясните, а то для моих скудных познаний stack guard-page выглядит слишком костыльно.
| | |
| |
| 2.15, key (??), 22:43, 19/06/2017 [^] [^^] [^^^] [ответить]
| +/– |
Конечно же код неправильный - границы стека и кучи меняются. При выделении памяти надо проверять, что не заходим за чужой диапазон. Но суть вопроса остается.
| | |
| 2.16, 123 (??), 22:48, 19/06/2017 [^] [^^] [^^^] [ответить]
| +/– | |
>>Там же неверняка накладные расходы на реализацию защищенной страницы не меньше?
Этим вроде как менеджер памяти ОС должен заниматься. Поэтому меньше должно быть.
| | |
| |
| 3.17, Аноним84701 (ok), 22:52, 19/06/2017 [^] [^^] [^^^] [ответить]
| +/– |
 >>>Там же неверняка накладные расходы на реализацию защищенной страницы не меньше?
> Этим вроде как менеджер памяти ОС должен заниматься. Поэтому меньше должно быть.
Оно по-любому меньше будет, потому как в первом случае проверка при каждой операции, а вот при использовании guard-page - только непосредственно при обращении к данному региону.
| | |
| |
| 4.20, 123 (??), 23:08, 19/06/2017 [^] [^^] [^^^] [ответить]
| +/– | |
>>только непосредственно при обращении к данному региону.
"Обращение к региону" это выход push за пределы страницы? Пойду побью себя Таненбаум-ом по голове, освежу основы на всякий случай.
| | |
| |
| 5.22, Аноним84701 (ok), 23:14, 19/06/2017 [^] [^^] [^^^] [ответить]
| +/– | |
> "Обращение к региону" это выход push за пределы страницы?
Ну да, а что?
Я толком правда уже не помню, но вроде как прилетает pagefault-эксепшн со стороны железа (x86) при попытке чтения, записи и т.д. без соответсвующего флажка страницы.
| | |
|
|
|
| 2.19, Аноним84701 (ok), 23:00, 19/06/2017 [^] [^^] [^^^] [ответить]
| +/– |
> Там же неверняка накладные расходы на реализацию защищенной страницы не меньше?
> Объясните, а то для моих скудных познаний 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
и поэтому лепить для защиты стековых переменных/фрейма выходит вроде как все еще несколько накладно.
| | |
| |
| 3.32, Аноним (-), 06:58, 20/06/2017 [^] [^^] [^^^] [ответить]
| +2 +/– |
>[оверквотинг удален]
> PROT_EXEC
> The pages can be executed
> И кончено, оно наамного быстрее костылей с проверками при каждой операции.
> Единственно, памяти "тратится" минимум PAGE_SIZE
>
> getconf PAGE_SIZE
> 4096
>
> и поэтому лепить для защиты стековых переменных/фрейма выходит вроде как все еще
> несколько накладно.
Стоит уточнить, что «тратится» из-за сторожевых страниц не просто память, а именно виртуальная; в физическую память это страницы не отображаются, поэтому все накладные расходы связаны с поддержанием служебных таблиц виртуальной памяти (чем они больше, чем чаще ЦП при обращении к ним промахивается мимо кэша и тем дольше их простой перебор).
| | |
|
| 2.46, Ordu (ok), 11:43, 20/06/2017 [^] [^^] [^^^] [ответить]
| +2 +/– |
 > Там же неверняка накладные расходы на реализацию защищенной страницы не меньше?
Stack guard страница фактически не требует никаких накладных расходов, она один раз ядром помечается как недоступная для приложения, а потом процессор генерит исключение когда к ней происходит обращение. Процессор постоянно проверяет эти права, не только для охранной страницы, а для всех.
А вот указатель стека проверять -- это реально накладные расходы, потому что стек реально реализован через регистр rbp, который указывает на вершину стека, и приложение с ним может играть как угодно. Выделить память под новый стек из кучи и нацелить rbp туда, например. Есть даже готовые функции в libc для подобной игры с rbp: о них можно почитать в info libc 'Non-Local exits'.
Большая часть софта не делает этого, оставляя всю работу со стеком компилятору. Но даже там проверки указателя стека могут оказаться накладным удовольствием. Указатель стека меняется при каждом вызове функции, при каждой инструкции push/pop, при каждом объявлении локальной переменной в C... И при этом компилятор, в общем-то, не знает границ стека, об этом наверное только компоновщик узнаёт, тот которые объектные файлы в готовый бинарь собирает. А может быть даже и он не знает, а уже динамический компоновщик устанавливает эти границы, когда грузит бинарь в память процесса. Но с этими тонкостями я не разбирался.
| | |
| |
| 3.48, Олег (??), 12:03, 20/06/2017 [^] [^^] [^^^] [ответить]
| +2 +/– |
 rbp указывает на начало фрейма функции, на вершину стека указывает rsp
| | |
| |
| 4.49, Ordu (ok), 12:22, 20/06/2017 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> rbp указывает на начало фрейма функции, на вершину стека указывает rsp
Да, спасибо за поправку.
| | |
|
|
|
| 1.23, Аноним (-), 23:40, 19/06/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
У меня с -fstack-check localedef в glibc падает в сегфолт. Проверьте, так же у вас?
2.24
| | |
| |
| 2.29, Crazy Alex (ok), 02:34, 20/06/2017 [^] [^^] [^^^] [ответить]
| +4 +/– |
 Ну, подход "давайте смиримся с кривым кодом и просто распихаем по песочницам" нравится не всем. Так как создаёт больно уж много тормозов и неудобств.
| | |
| 2.31, Аноним (-), 06:37, 20/06/2017 [^] [^^] [^^^] [ответить]
| +/– | |
> И эти же анонимы ржут по поводу Hurd. Ну ржите...
И где твой Hurd? Почему, если он такой безопасный, его до сих пор не внедрили, а взяли почему-то Linux.
| | |
| 2.33, angra (ok), 07:46, 20/06/2017 [^] [^^] [^^^] [ответить]
| +2 +/– |
 А чем бы помог Hurd в большинстве указанных случаев? Ну кроме того, что он на той стадии развития, когда о защитах вроде stack guard-page еще не думают, а значит подобные эксплоиты это оверкилл.
| | |
| 2.34, Elhana (ok), 08:36, 20/06/2017 [^] [^^] [^^^] [ответить]
| +2 +/– |
 Можно подумать, что с Hurd все эти проблемы в статье магическим образом решаются.
| | |
| |
| 3.37, Аноним (-), 09:32, 20/06/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
Там же микроядро ! Они магическим образом решает все проблемы.
| | |
| 3.38, Tim (??), 09:33, 20/06/2017 [^] [^^] [^^^] [ответить]
| +2 +/– | |
В Linux, по историческим причинам, используется плоская модель памяти, т.е. код, данные, куча и стек находятся в едином адресном пространстве. Вся защита строится на ограничении доступа записи к отдельным страницам и рандомизации размещения.
Куча и стек _должны_ быть доступны на запись. Регистр процессора "указатель на вершину стека" доступен на запись, это необходимо для организации фрейма локальных данных.
Достаточно установить стековый регистр или регистр начала фрейма на валидный адрес и "stack guard-page" ничем не поможет.
В системах с сегментной организацией памяти таких проблем нет.
| | |
| |
| 4.43, yet another anonymous (?), 11:00, 20/06/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
> В Linux, по историческим причинам, используется плоская модель памяти, ...
> В системах с сегментной организацией памяти таких проблем нет.
Не назовет ли автор действующие операционки с прогрессивной сегментной организацией? ;)
| | |
| |
| 5.51, Tim (??), 13:53, 20/06/2017 [^] [^^] [^^^] [ответить]
| +3 +/– | |
Последняя была в 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).
| | |
| |
| 6.52, Crazy Alex (ok), 14:18, 20/06/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ну так главный знает, что говорит. Потребности в безопасности - они у всех разные, начиная с полного отсутствия и заканчивая высями небесными. Поэтому первичным должно быть решение задач, а безопасность (с сопутствующими накладными расходами) - добавляться/убавляться по необходимости.
| | |
|
|
| 4.54, добрый (?), 14:38, 20/06/2017 [^] [^^] [^^^] [ответить]
| +/– |
Вот только в AMD64 от сегментации избавились, поспешно и неосмотрительно.
| | |
| |
| 5.61, Tim (??), 16:03, 20/06/2017 [^] [^^] [^^^] [ответить]
| +1 +/– | |
При переключении контекста задач, требуется подгрузить таблицу трансляции адресов для каждого сегмента. Это вызывает шоковую нагрузку на кэш процессора.
В AMD64 шина адреса 48 бит, при этом, мнимальный размер страницы 4kB, т.е. отбрасываем 12 бит и получаем 2^36 записей в таблице трансляции. Это много, даже для иерархического представления MMU x86.
Избавились поспешно, но осмотрительно. ;)
| | |
| |
| 6.65, добрый (?), 16:48, 20/06/2017 [^] [^^] [^^^] [ответить]
| +/– |
> При переключении контекста задач, требуется подгрузить таблицу трансляции адресов для
> каждого сегмента.
Нет, не требуется. Страничные таблицы никогда не подгружаются в кэш заранее целиком.
> Это вызывает шоковую нагрузку на кэш процессора.
Нет, не вызывает. Единственная "шоковая" нагрузка - это сброс TLB, который при переключении контекста (не режима) происходит в любом случае, будь там хоть один сегмент, хоть несколько.
> В AMD64 шина адреса 48 бит, при этом, мнимальный размер страницы 4kB,
> т.е. отбрасываем 12 бит и получаем 2^36 записей в таблице трансляции.
> Это много, даже для иерархического представления MMU x86.
Это всё к делу совершенно не относится.
> Избавились поспешно, но осмотрительно. ;)
По совершенно другим причинам. Осмотрительно или не - спорить не вижу смысла.
| | |
| |
| 7.70, J.L. (?), 18:48, 20/06/2017 [^] [^^] [^^^] [ответить]
| +/– |
 >> Избавились поспешно, но осмотрительно. ;)
>По совершенно другим причинам.
можно узнать по каким ? мне сильно не понятен этот вопрос и почему вообще отказались от сегментной модели памяти типа 486х ?
| | |
| |
| 8.72, добрый (?), 21:21, 20/06/2017 [^] [^^] [^^^] [ответить] | +/– | Моральное устаревание На тот момент сегменты кода, данных и стека с разными адр... текст свёрнут, показать | | |
| |
| 9.74, J.L. (?), 13:32, 22/06/2017 [^] [^^] [^^^] [ответить] | +/– | и сейчас нет в современном процессоре механизма на запрет чтение запись исполнен... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
| |
| 2.58, пох (?), 15:28, 20/06/2017 [^] [^^] [^^^] [ответить]
| +/– | |
> rhel5 x64 подвержен ?
судя по приехавшему сегодня патчу ведра - да.
Патчей sudo, ld.so и всего прочего - вероятно, не дождетесь. А патч ведра защищает только от poc-эксплойтов квалиса, и то если повезло, а не от любых других.
| | |
| |
| |
| 4.69, пох (?), 17:52, 20/06/2017 [^] [^^] [^^^] [ответить]
| +/– | |
> интересно, а сентос обновит или забьет ?
а они разьве поддерживают пятую версию?
| | |
|
|
|
| 1.73, Аноним (-), 13:12, 22/06/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Нужно реализовать аппаратную поддержку маркировки страниц как стек и куча с проверкой процессором, что адресации относительно rsp идут на страницу со стеком, а остальные - на страницы с кучей.
| | |
|
