защита стеков

[Andrey Cherezov]

Привет!

Прилагаю эксперименты по защите стеков от переполнения/исчерпания.
TEST'ы - для испытания защиты.

В исходном варианте (без вызова MEMPROT) только TEST3 (исчерпание стека
данных) дает ловимое исключение, остальные три теста слетают.

При выделении стека данных в отдельную область памяти с защитой её
границ аппаратно. TEST (переполнение стека данных) ловится нормально,
TEST3 тоже ловится лучше - на первой же попытке взять ниже вершины.

А вот переполнение/исчерпание стека возвратов поймать не удается. Точнее,
ловить вроде как удается (тем же способом - аппаратной защитой границ), но
обработать - нет. Т.е. выглядит это по-прежнему как вылет. Видимо дело в
обработчике - в (ENTER) на входе в (EXT):
- если попадаем в обработчик при переполнении стека возвратов, то первый
же PUSH (внутри (ENTER)) вызывает вложенное исключение, т.е. вылет.
- если исключение при исчерпании стека возвратов, то на тот момент
видимо уже затерт SEH-фрейм с адресом нашего обработчика.

Есть идеи, как лучше ловить сбои с RP ? Защитой SEH-фрейма? (он меньше
страницы - защитой RP сделается вообще неюзабельным). Выносом SEH
в отдельную область памяти? Переписью (EXT) или заменой там (ENTER)?

Кстати, относительно свежая статья про SEH:
http://wasm.ru/article.php?article=veh

--
Андрей

WINAPI: VirtualProtect KERNEL32.DLL
WINAPI: VirtualAlloc KERNEL32.DLL

  0x02 CONSTANT PAGE_READONLY
  0x04 CONSTANT PAGE_READWRITE
0x1000 CONSTANT MEM_COMMIT
0x2000 CONSTANT MEM_RESERVE


: MEMPROT
  PAGE_READWRITE MEM_COMMIT MEM_RESERVE OR 16 1024 * 0 VirtualAlloc DUP 0= THROW >R
  PAD PAGE_READONLY 4096 R@ VirtualProtect 0= THROW
  PAD PAGE_READONLY 4096 R@ 4096 3 * + VirtualProtect 0= THROW
  R> 4096 3 * + 4 - DUP S0 ! SP!

  100000 BEGIN DUP >R 1- DUP 0= UNTIL DROP
  100000 BEGIN RDROP 1- DUP 0= UNTIL DROP
  PAD PAGE_READONLY 2 R0 @ 400000 - VirtualProtect 0= THROW
  PAD PAGE_READONLY 2 R0 @ 4092 + DUP HEX U. DECIMAL VirtualProtect 0= THROW
;
MEMPROT

\ òåñòû ïåðåïîëíåíèÿ
: TEST
  BEGIN
    9 DEPTH .
  AGAIN
;
: TEST2
  BEGIN
    9 >R RP@ R0 @ - .
  AGAIN
;

\ òåñòû èñ÷åðïàíèÿ
: TEST3
  BEGIN
    DROP DEPTH .
  AGAIN
;
: TEST4
  BEGIN
    RDROP RP@ R0 @ - .
  AGAIN
;

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev

[Andrey Cherezov]

Добрый день!

Моё сообщение от 01.10.2007 7:10:
> Есть идеи, как лучше ловить сбои с RP ? Защитой SEH-фрейма? (он меньше
Ну что ж вы молчите, братцы?
Никто не напомнил про ~ss/ext/stack-guard.f :)


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev

[Ruvim Pinka]

Привет!

On 10/1/07, Andrey Cherezov <[hidden email]> wrote:

Есть идеи, как лучше ловить сбои с RP ? Защитой SEH-фрейма? (он меньше
страницы - защитой RP сделается вообще неюзабельным). Выносом SEH
в отдельную область памяти? Переписью (EXT) или заменой там (ENTER)?

При переполнении или исчерпании стека возвратов, или просто неверном значении указателя (типа 0 RP! ) процесс чаще всего падает, т.к. исключение возникает в самом системном обработчике исключений (из ntdll, который обрабатывает цепочку SEH), т.к. он работает на текущем ESP (а теоретически, мог бы перейти на стек в специальном буфере на этот случай). Управление до (EXC) просто не доходит, поэтому его изменение погоды не сделает. Доступный вариант, на самый уж крайняк — обработчик аппаратных исключений в отдельном процессе (регистрируется как процесс-отладчик).

Вынос фрейма SEH в отдельную область памяти, вне стека, предоставленного системой, тоже влечет падение. После set-exc-handler2 (код ниже) исключения обрабатываются нормально, как и было, а после set-exc-handler3 процесс живет лишь до первого аппаратного исключения. Возможно, область памяти для этого фрейма требует каких-то особых установок на страницы.

Что касается VEH (установка обработчика через системную функцию AddVectoredExceptionHandler), то ситуация при неверном указателе аппаратного стека полностью аналогична. Отсутствие необходимости фрейма в стеке для VEH вряд ли сыграет какую-то роль, когда системный обработчик исключений все-равно неработоспособен.


Код для эксперимента, расположение фрейма SEH в системной стеке и в иной области памяти:

: set-exc-handler2
  TlsIndex@ >R
  ['] (EXC) >R
  0 FS@     >R

  RP@ 0 FS!
  QUIT \ чтобы не делать трюк с подкладыванием фрейма под верхнии значения R-стека.
;

: set-exc-handler3
  ALIGN HERE
  0 FS@     ,
  ['] (EXC) ,
  TlsIndex@ ,

  0 FS!
;


--
Ruvim
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev

[Andrey Cherezov]

Some javascript/style in this post has been disabled (why?)

Добрый день, Ruvim Pinka!

Ваше сообщение от 14.10.2007 18:02:

При переполнении или исчерпании стека возвратов, или просто неверном значении указателя (типа 0 RP! ) процесс чаще всего падает, т.к. исключение возникает в самом системном обработчике исключений (из ntdll, Вынос фрейма SEH в отдельную область памяти, вне стека, предоставленного системой, тоже влечет падение. Что касается VEH (установка обработчика через системную функцию AddVectoredExceptionHandler), то ситуация при неверном указателе аппаратного стека полностью аналогична. Отсутствие необходимости фрейма в стеке для VEH вряд ли сыграет какую-то роль, когда системный обработчик исключений все-равно неработоспособен.

Резюме: со стеком возвратов полная безнадёга.

Остается вносить контроль границ внутрь RP!, >R и т.д. Но внешние dll в таком случае по-прежнему будут бесконтрольны.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev