01.06.2011

Обход функционала SEHOP для эксплуатации переполнения буфера

Недавно корпорация Microsoft ввела в своих продуктах новый функционал безопасности под названием «Защита от перезаписи обработчика структурных исключений» (SEHOP).

Авторы:

Stéfan Le Berre s.leberre@sysdream.com
Damien Cauquil d.cauquil@sysdream.com

0. Вступление

Недавно корпорация Microsoft ввела в своих продуктах новый функционал безопасности под названием «Защита от перезаписи обработчика структурных исключений» (SEHOP). Данный функционал присутствует в таких операционных систем, как:

  • Microsoft Windows 2008 SP0
  • Microsoft Windows Vista SP1
  • Microsoft Windows 7
Пока не было зафиксировано нацеленных на отключение данного функционала атак, но в сети Интернет уже появилось множество ресурсов с описанием самого функционала, а также его надежности. SEHOP считается настолько надёжным, что Microsoft выпустила патч, позволяющий, по умолчанию, активировать его для всех программ. Неужели, истории с переполнениями буфера в Windows пришел конец? При определенных обстоятельствах вовсе нет, но об этом речь пойдет ниже.

1. Технические спецификации SEHOP (краткая версия)

SEHOP расширяет обработку структурных исключений и применяет большое количество проверок безопасности структуры обработки исключений (SEH), используемой программами. Основная функция SEHOP заключается в проверке всех SEH структур в обрабатываемом стеке, особенно последней SEH структуры, которая имеет особое значение, так как ее обработчик указывает прямо на функцию файла библиотек. Вот классический пример SEH цепочки:

Каждая SEH структура в цепочке указывает на последующую структуру, а последняя структура, в свою очередь, содержит обработчик, указывающий на ntdll!_except_handler4. При эксплуатации перезаписи SEH структуры стека, последующий SEH указатель получает некий байт-код, а измененный SEH обработчик указывает на последовательность инструкций «POP POP RET», расположенных за пределами SafeSEH модуля.
Используемый в SEHOP алгоритм валидации был описан А.Сотировым (A. Sotirov) на конференции Black Hat в 2008 году. Давайте рассмотрим его:

Также, необходимо помнить о сопутствующих ограничениях:

  • SEH обработчик должен указывать на последовательность инструкций, расположенных за пределами SafeSEH модуля
  • Страница должна быть исполняемой
  • Цепочка SEH не должна изменяться и должна оканчиваться SEH-структурой, содержащей особое значение (0xFFFFFFFF как следующий структурный указатель, определенное значение, как SEH обработчик)
  • Все SEH структуры должны иметь 4-байтное смещение
  • Последний обработчик SEH структуры должен указывать прямо на ntdll на ntdll!FinalExceptionHandler
  • Все SEH указатели должны указывать на местоположения стека

2. SEHOP и эксплуатация переполнения буфера в стеке

2.1 Расширение классической схемы эксплуатации

Так работает классическая схема эксплуатации:



SEH обработчик указывает на последовательность инструкций «POP POP RET», а первый член структуры, вместо действительного адреса стека, содержит код. При обработке исключений Windows передает управление обработчикам исключений, согласно SEH цепочке. Первый обработчик исключений перезаписывается, а процесс исполнения направляется на последовательность инструкций «POP POP RET» (вместо обработки исключения). Данная последовательность передает процесс выполнения первым двум байтам первого члена текущей SEH структуры, являющей собой jump инструкцию (0xEB06). Таким образом, SEH цепочка разрывается:



Два первых байта первого DWORD в SEH структуре никогда не выполняются. Их можно изменить, таким образом, сделав DWORD действительным контролируемым адресом стека. Также, существует возможность изменения остальных двух байт, которые будут указывать на действительный контролируемый адрес стека. Еще их можно определить как jump инструкцию. DWORD можно считать как действительным адресом стека, так и действительной командой, при вызове выполняющей jump.
Если поместить ложную SEH структуру в адрес стека, указанный первым DWORD, то удастся изменить всю SEH цепочку, а также получить контроль над SEH структурой. Сделать ее валидной нам поможет подтверждение первой SEH структуры.

2.2 Сложная часть

Нужно решить основной вопрос: какую jump инструкцию можно запрограммировать таким образом, чтобы ее байт-код отображал адрес с 4-байтным смещением. Здесь подходит только одна инструкция: JE (закодированная в виде 0x74). Данная команда представляет собой условный jump. Jump выполняется, если установлен флаг Z. При обработке исключений, флаг Z в Windows по умолчанию не выставляется, его необходимо установить путем выполнения инструкций вычисления, например, нулевого значения. Для этого может хорошо подойти оператор “XOR”. Решение нашей задачи становиться ясным: необходимо переключиться на последовательность «XOR, POP, POP, RET» для того, чтобы интерпретировать команду JE в JMP. В этом и заключалась сложная часть техники обхода SEHOP.
Инструкции «XOR, POP, POP, RET» найти несложно, некоторые последовательности можно найти в конце функций, возвращающихся к нулевому результату:

  • XOR EAX, EAX
  • POP ESI
  • POP EBP
  • RET

Чтобы быть уверенным в успешной эксплуатации, мы добавим в наш PoC код инструкции «XOR, POP, POP, RET».
Предположим, что по адресу 0x0022FD48 находится первая SEH структура. Можно создать еще одну SEH структуру по адресу 0x0022FD74, содержащую следующий SEH указатель со значением 0xFFFFFFFF и обработчиком, указывающим на ntdll!FinalExceptHandler. Если сделать так, чтобы обработчик первой структуры указывал на последовательность «XOR, POP, POP, RET», то появится возможность перенаправления хода выполнения в необходимом направлении, не разрывая при этом саму цепь. По сути, восстанавливается валидная ложная SEH цепочка, которая перенаправляет ход выполнения в специальный шеллкод.
Основным ограничением является ASLR, присутствующий в Microsoft Windows 7 и Vista. Успех эксплуатации зависит от знания адреса ntdll!FinalExceptHandler. При каждой перезагрузке системы, ImageBase Ntdll в случайном порядке изменяется, что значительно усложняет эксплуатацию. Произведенные с ASLR тесты (без реверсинга) показали, что из 16 битов, представляющих ImageBase, только 9 битов изменяются в случайном порядке. Это означает, что при попытке эксплуатации переполнения буфера, вероятность обхода SEHOP равна 1 к 512.

3. Proof Of Concept

3.1. Атакуемое приложение и ограничения

Для демонстрации работы вышеуказанной техники было создано небольшое приложение. Это приложение копирует содержимое файла «OwnMe.txt» в память и, по ходу операции, разбивает стек, вызывая исключения, перехватываемые обработчиком исключений.
Необходимые действия:

  • создать валидную ложную SEH цепь
  • заставить последний обработчик SEH структуры указывать на ntdll!FinalExceptionHandler
  • поместить совместимый с Windows 7 шеллкод в стек
  • определить местоположение последовательности «XOR, POP, POP, RET» в памяти

Последовательность «XOR, POP, POP, RET» известна потому, что мы поместили ее в код программы. Данную последовательность можно найти в памяти по адресу 0x004018E1.

3.2. Аварийно завершение и эксплуатация

При аварийном завершении работы программы, получаем:

  • 0012F700   41414141 указатель на следующую SEH запись
  • 0012F704   41414141  SEH обработчик

После этого, необходимо создать валидную ложную SEH цепь со второй SEH структурой, расположенной по адресу 0x0012F774 и содержащей 0xFFFFFFFF в качестве первого члена структуры (следующий SEH указатель) и FinalExceptionHandler в качестве SEH обработчика. Затем, содержимое SEH структуры, расположенной по адресу 0x0012F700, изменяется и указывает на созданную нами ложную SEH структуру, а обработчик устанавливается в значение 0x004018E1. Во избежание выполнения данных, перед каждой SEH структурой помещается jump инструкция (JMP +8).
При эксплуатации, выполнение должно происходить таким образом:

Шеллкод запустит calc.exe:

4. Заключение

Сам по себе функционал SEHOP не является надежной защитой от переполнения буфера в стеке. В этой статье был продемонстрирован способ обхода «Защиты от перезаписи обработчика структурных исключений». В то же время, SEHOP является весьма эффективным в связке с ASLR и DEP.

5. Ссылки

http://sysdream.com/
http://ghostsinthestack.org/
http://virtualabs.fr/

6. Литература

 [1] Preventing the Exploitation of Structured Exception Handler (SEH) Overwrites with SEHOP:
http://blogs.technet.com/srd/archive/2009/02/02/preventing-the-exploitation-of-seh-overwrites-
with-sehop.aspx
[2] SEHOP per-process opt-in support in Windows 7:
http://blogs.technet.com/srd/archive/2009/11/20/sehop-per-process-opt-in-support-in-windows-
7.aspx
[3] Bypassing Browser Memory Protections: http://taossa.com/archive/bh08sotirovdowd.pdf
[4] ZIP containing our target program & exploit http://www.sysdream.com/SEHOP.zip

или введите имя

CAPTCHA
02-06-2011 15:41:35
Метод требует подмены точки возврата в стеке используемый командой RET. Факт перезаписи точки возврата в стеке легко контролируется аппаратурой ЦП. Пример такого контроля здесь : http://www.vmgu.ru/articles/hardware-virtualization-antiviruses Причем это не единственная возможность.
0 |
03-06-2011 13:37:04
Вообще то метод описанный тут тербует подмены SEH и nSEH. Правда тоже в стеке и это тоже возможно котролировать аналогичным методом Только как контролировать, например, ВСЕ указатели в VTABLE от перезаписи? Или блокировать атаки типа Dangler Pointer или Use-After-Free? Короче, как мне кажется, не все так просто
0 |
имя
03-06-2011 14:23:54
видимо опечатка: Microsoft Windows 2008 SP0
0 |
03-06-2011 14:41:43
А в чем состоит опечатка?
0 |
anon
04-06-2011 00:02:55
Такой версии не существует в природе. есть Windows 2008 Server RTM. так называемое "золото". никаких SP0 нет
0 |
Миша
15-06-2011 19:36:53
Статья хорошая, но перевод не понравился, хоть и видно, что автор старался. Прошу ссылку на оригинал.
0 |