Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Господа, будьте снисходительны, не бросайтесь сразу штрафовать за, как вам кажется, глупые вопросы - beginners на то и beginners.
| | |
Re: VirtualProtect 23.06.03 14:36 Число просмотров: 1287
Автор: XR <eXtremal Research> Статус: The Elderman
|
Насколько я зная компиляторы могут что то подобное юзать опционально ... но там это дело вроде бы используется не для защиты как таковой а для контроля размера стека - типа нарушил защиту - раздвинул стек ... НО проблемы это не снимает да и используется эта фича в отладочном режиме (то что это тормоза совершенно очевидно )- я к сожалению особо подробно в это дело не вникал может кто сможет рассказать про это дело более развернуто
|
|
<beginners>
|
исполняемый стек 19.06.03 12:45
Автор: diov Статус: Незарегистрированный пользователь
|
Извините, что не в форуме "operating systems". Этот вопрос скорее туда.
Что заставляет разработчиков ОС делать сегмент стека исполняемым?
Это беда самых популярных ОС. Хочется понять причины, которые к приводят к такому положению.
Наверняка создателям приходили в голову такие вопросы...
|
|
исполняемый стек 19.06.03 13:22
Автор: XR <eXtremal Research> Статус: The Elderman
|
> Извините, что не в форуме "operating systems". Этот вопрос
> скорее туда.
>
> Что заставляет разработчиков ОС делать сегмент стека
> исполняемым?
> Это беда самых популярных ОС. Хочется понять причины,
> которые к приводят к такому положению.
Причина очень простая - скорость доступа к стеку ...
>
> Наверняка создателям приходили в голову такие вопросы...
Есть различные способы сделать стек неисполняемым (либо отследить сискол из сегмента стека) в том числе и для x86
наиболее популярные решения для x86
это
1) PAX (есть реализации для linux и NT)
2) openwall (для linux)
|
| |
Sorry, вопрос может и глуп, но все же: а почему бы приложению, которое хочет защититься таким образом, не вызвать VirtualProtect ? 21.06.03 09:59
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 21.06.03 10:02 Количество правок: 1
|
|
|
| | |
Re: VirtualProtect 23.06.03 14:36
Автор: XR <eXtremal Research> Статус: The Elderman
|
Насколько я зная компиляторы могут что то подобное юзать опционально ... но там это дело вроде бы используется не для защиты как таковой а для контроля размера стека - типа нарушил защиту - раздвинул стек ... НО проблемы это не снимает да и используется эта фича в отладочном режиме (то что это тормоза совершенно очевидно )- я к сожалению особо подробно в это дело не вникал может кто сможет рассказать про это дело более развернуто
|
| | | |
Re[2]: VirtualProtect 24.06.03 16:17
Автор: amirul <Serge> Статус: The Elderman
|
> Насколько я зная компиляторы могут что то подобное юзать
> опционально ... но там это дело вроде бы используется не
ВиртуалПротект может менять права на СТРАНИЦЫ, а в x86 архитектуре нельзя выставлять страницам запрет на исполнение (исполнение можно разрешать/запрещать только СЕГМЕНТАМ). Стек в любом случае должен оставаться RW, а даже если и запретить для селектора SS исполнение, то, как уже было замечено, flat модель позволяет обратиться к той же странице через другой селектор (в частности cs, для которого исполнение должно быть всегда).
> для защиты как таковой а для контроля размера стека - типа
> нарушил защиту - раздвинул стек ... НО проблемы это не
Guard Page в стеке есть всегда (и в Release тоже - это фича ОСи, а не компилятора) и у нее сброшен бит P (present). В Optional Header-е у PE exe-шника указывается Stack Commit Size (по умолчанию 0x4000) - сколько стека физически выделяется при создании процесса, и Stack Reserved Size (по умолчанию 0x100000) - до каких пор может расти стек за счет этой самой Guard Page. Стек расширяется в обработчике Page Fault-а, когда происходит обращение к Guard Page-у, а сама эта пага сдвигается дальше.
> снимает да и используется эта фича в отладочном режиме (то
> что это тормоза совершенно очевидно )- я к сожалению особо
> подробно в это дело не вникал может кто сможет рассказать
> про это дело более развернуто
В общем случае проблему срыва стека на x86 flat модели решить нельзя. Расширение стек-фрейма для функции и введение туда разных проверочных данных помогает только для отладки своих программ, т.к. эксплоит, который сорвал стек процесса чаще всего никогда не возвращает управление и следовательно никогда не выполняет код, который мог бы проверить состояние стека на выходе из функции.
|
| | | | |
Да, печально. Остался последний вопрос... 25.06.03 20:36
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 25.06.03 20:37 Количество правок: 1
|
PAGE_READONLY
PAGE_READWRITE
PAGE_WRITECOPY
PAGE_EXECUTE
PAGE_EXECUTE_READ
PAGE_EXECUTE_READWRITE.
PAGE_EXECUTE_WRITECOPY
PAGE_GUARD
PAGE_NOACCESS
PAGE_NOCACHE (модификатор)
Столько приятных на первый взгляд режимов доступа к страницам открывает VirtualProtect... Однако PAGE_READWRITE функционально равно PAGE_EXECUTE_READWRITE на Intel... Столько режимов из-за мультиплатформенности, т.е. на других платформах (NT4 + DEC Alpha, к примеру), это не так?
|
| | | | | |
Да, печально. Остался последний вопрос... 26.06.03 12:58
Автор: amirul <Serge> Статус: The Elderman
|
> PAGE_READONLY
> PAGE_READWRITE
> PAGE_WRITECOPY
> PAGE_EXECUTE
> PAGE_EXECUTE_READ
> PAGE_EXECUTE_READWRITE.
> PAGE_EXECUTE_WRITECOPY
> PAGE_GUARD
> PAGE_NOACCESS
> PAGE_NOCACHE (модификатор)
> Столько приятных на первый взгляд режимов доступа к
> страницам открывает VirtualProtect... Однако PAGE_READWRITE
> функционально равно PAGE_EXECUTE_READWRITE на Intel...
> Столько режимов из-за мультиплатформенности, т.е. на других
> платформах (NT4 + DEC Alpha, к примеру), это не так?
Ага. Причем ноги у сегментации растут от backward compatibilyty с 8086 и т.д.. На том же 680x0 все необходимое разделение можно сделать при помощи страниц. И запретить исполнение в странице тамошний MMU может. Причем возможно до 5 уровней разбиения на страницы с произвольной (устанавливаются в спец регистрах) битовостью каждого уровня. В x86 существует только 3 жестко заданных уровня: 10 бит - индекс в PD, 10 - в PT, и 12 - смещение на странице.
Кста, flat-модель - не столько признак криворукости или лени программистов, сколько забота о портабельности. Уж очень на многих платформах вообще не существует понятия подобного сегментам (всегда удобнее работать с линейной памятью). И вся необходимая функциональность ложится на страничный обмен. И это правильно. Как сказал еще Оккам: "Не вводи сущности сверх необходимости". Два механизма, выполняющие в сущности одно и то же - явный перебор.
Ничего не имею против Intel, но x86 - не самый лучший пример продуманной архитектуры.
|
| |
исполняемый стек 19.06.03 14:13
Автор: diov Статус: Незарегистрированный пользователь
|
> Причина очень простая - скорость доступа к стеку ...
Хым... непонятно, почему
push, pop, call, ret, ...
- замедлятся, если убрать флаги исполняемости?
> Есть различные способы сделать стек неисполняемым (либо
> отследить сискол из сегмента стека) в том числе и для x86
Проверка сис-call-ов - хорошая идея...
> наиболее популярные решения для x86
>
> это
>
> 1) PAX (есть реализации для linux и NT)
> 2) openwall (для linux)
|
| | |
исполняемый стек 19.06.03 14:40
Автор: cb <cb> Статус: Member
|
> Хым... непонятно, почему
> push, pop, call, ret, ...
> - замедлятся, если убрать флаги исполняемости?
если я ничего не путаю, то замедляет не отсутствие флагов, а то что сегмент стека имеет селектор отличный от текущего...
cb.
|
| | |
исполняемый стек 19.06.03 14:38
Автор: XR <eXtremal Research> Статус: The Elderman
|
> > Причина очень простая - скорость доступа к стеку ...
> Хым... непонятно, почему
> push, pop, call, ret, ...
> - замедлятся, если убрать флаги исполняемости?
AFAIK x86 это (nonexec page) не умеет (PAX правда умеет это обходить через одно место :))
а размещать стек в своем сегменте это обрекать себя на межсегментные переключения ...
>
> > Есть различные способы сделать стек неисполняемым
> (либо
> > отследить сискол из сегмента стека) в том числе и для
> x86
> Проверка сис-call-ов - хорошая идея...
Ну да - когда точно известна структура памяти user space задачи
это работает (см openwall)
http://www.openwall.com
> > наиболее популярные решения для x86
> >
> > это
> >
> > 1) PAX (есть реализации для linux и NT)
> > 2) openwall (для linux)
|
| | | |
исполняемый стек 20.06.03 05:10
Автор: Zef <Alloo Zef> Статус: Elderman
|
|
Я вообще до сих пор не втыкаюсь, почему все операционки юзают флэт модель? Размещение буферов каждого в своем сегменте позволяет на системном уровне "железно" защитить их от переполнения. Селекторы кэшируются и для современных камней потери на переключение незначительны, а безопасность и стабильность системы возрастает многократно.
|
| | | | |
исполняемый стек 20.06.03 09:43
Автор: diov Статус: Незарегистрированный пользователь
|
> Я вообще до сих пор не втыкаюсь, почему все операционки
> юзают флэт модель?
> Селекторы кэшируются и для современных
> камней потери на переключение незначительны,
Опять непонятно: о каком переключении сегментов идет речь?
Например: SS указывает в один сегмент, DS - в другой, и переключения задач не происходит.
Подведем итоги.
Выслушав все замечания, раскопав пыльную книжку про защищенный режим процессоров x86, можно сделать выводы:
1. вся фигня из-за флэт модели
2. page-таблица в PM режиме не позволяет различать флаги чтения от исполнения для страницы
Несмотря на то, что дескрипторы для SS, DS, ES, FS могут иметь "правильные" флаги, из-за флэт модели возможно записать в одно место памяти через эти сегментные регистры, а затем исполнить его через CS.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
