Центр информации по операционным системам: Новости / Комментарии / SecurityLab.ru: Обход аппаратной реализации DEP в Windows

Одним из самых значительных изменений, представленных Microsoft в Windows XP Service Pack 2 и Windows 2003 Server Service Pack 1, было поддержка новой возможности, названной Data Execution Prevention (DEP). DEP может работать в двух режимах. Первый режим называется Программный DEP (Software-enforced DEP) и обладает ограниченной функциональностью, способ обхода программного DEP был описан ранее. Второй режим работы DEP – аппаратный (Hardware-enforced DEP). Он используется в тех случаях, когда аппаратное обеспечение поддерживает неисполняемые страницы памяти. Аппаратный DEP наиболее интересный режим, так как он действительно сильно затрудняет использование большинства методов атаки. В этой статье описана методика обхода DEP, работающего в аппаратном режиме.

Roman I Khimov в Воскресенье, 19 Март 2006, 22:02 |

Комментарии: 13 |

Комментарии

captain cobalt |20.03.2006 07:46

Комментарии: 83

Зарегистрирован: 04.07.2004 21:44

Это решение хуже чем предложенное более года назад.

Вот смотрите.

Можно сделать так:
-- открыть страницы для выполнения
-- передать управление на свой код

А можно сделать так:
-- передать управление на ось и приказать запустить шелл
-- свободно передавать команды запущенному шеллу

Второе решение потенциально более гибкое и не зависит от DEP.

Vadim Ushakov |20.03.2006 09:28

Комментарии: 78

Зарегистрирован: 18.08.2005 04:25

Насколько я понимаю, если бы MS не оставила "ради совместимости" возможность (или дыру?) отключать DEP прямо при работе процесса, то варианты атаки сократились бы до случая, когда мы затираем стек и перекидываем управление некому коду, который легально присутствует в процессе, но свой код передать и исполнить не можем?
В любом случае, бороться надо с причиной: если бы не было возможности переполнить буфер в стеке или куче, то не было бы и дыр. Может быть, все сетевые программы переписать на Обероне?

distar \|20.03.2006 12:44
Комментарии: 5 Зарегистрирован: 01.03.2006 13:22	или использовать сегментную адресацию памяти)

Roman I Khimov \|20.03.2006 12:55
Комментарии: 952	distar написал(а) ... или использовать сегментную адресацию памяти) ... которой нет уже даже в x86-64?..

distar |20.03.2006 16:24

Комментарии: 5

Зарегистрирован: 01.03.2006 13:22

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

Roman I Khimov |20.03.2006 16:49

Комментарии: 952

distar написал(а) ...
нет, потому что никто не хотел использовать, будут использовать - появится опять

А как ее использовать, если ее нет?

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

У меня есть молоток и есть гвозди. Известно, что гвозди фиговастенькие и то и дело норовят погнуться. Вопрос - что делать, попробовать изменить молоток так, чтобы он не гнул гвозди (создаем встроенную систему захвата гвоздя в нескольких точках, стабилизацию относительно прибиваемой плоскости и т.д. Собственно, это уже не совсем молоток получается а автоматическая система забивки гвоздей), или же все-таки взять нормальные гвозди?

То, что система в Intel продумана была, спору нет - над автозабивалкой тоже голову поломать надо ой-ой, только... зачем?

Dron |20.03.2006 16:56

Комментарии: 558

Сегменты рулили на 286... на 386 сегменты потеряли свой смысл...

В частности потому, что невозможно реализовать use32 сегменты стека - растущие вниз.

Так что недодумали тогда, а сейчас само отвалилось, потому что никому не надо.

А виндуз как всегда в своем ремертуаре... полумеры...

Vadim Ushakov \|20.03.2006 17:14
Комментарии: 78 Зарегистрирован: 18.08.2005 04:25	создаем встроенную систему захвата гвоздя в нескольких точках, стабилизацию относительно прибиваемой плоскости и т.д... Роман, срочно подавай заявку на патент!

distar \|20.03.2006 17:21
Комментарии: 5 Зарегистрирован: 01.03.2006 13:22	В частности потому, что невозможно реализовать use32 сегменты стека - растущие вниз. Огромный сегмент стека + страницы и не надо ему расти вниз

distar |20.03.2006 18:23

Комментарии: 5

Зарегистрирован: 01.03.2006 13:22

А как ее использовать, если ее нет?
в x86-32 пока

То, что система в Intel продумана была, спору нет - над автозабивалкой тоже голову поломать надо ой-ой, только... зачем?
спорить не буду - я давно уже не пишу на ассемблере и отошел от системного программирования, а к системному проектированию даже и не подходил

так что судить могу только как дилетант в данном деле, но точно помню что для своих поделок всегда делал базу сегментов данных, стека и комад разной! и это кстати не мешало использовать адресную арифметику си с его плоской моделью

Dron |20.03.2006 18:34

Комментарии: 558

огромный сегмент стека - это блин путь к вирусам прямой...

вот прямо как щас...

а вот растущий вних сегмент стека, естественон доступный только для данных и никак не пересекающийся собственно с сегментом данных! вот это круто!

Но такого даже компиляторы не умеют... только и умеют что flat... а потому что невозможно в принципе.

distar \|20.03.2006 18:54
Комментарии: 5 Зарегистрирован: 01.03.2006 13:22	огромный сегмент стека - это блин путь к вирусам прямой... с чего вдруг

Dron |20.03.2006 21:04

Комментарии: 558

потому что это равносильно отсутствию защиты стека вообще!

новые извращения с битом NP - это не от хорошей жизни.

следует от метить, что сегменты предоставляют максимальные возможности защиты... страницы - не для того предназначены.

Комментарии доступны только авторизованным пользователям, авторизуйтесь или зарегистрируйтесь на сайте здесь