Windows 2003 отключить dep

Обновлено: 01.07.2024

Начиная с ОС Windows XP и во всех последующих версиях системы Windows, есть такая функция как DEP. Ее можно расшифровать и перевести как «предотвращение выполнения данных». В некоторых случаях, работа данной службы создает определенные помехи и тогда возникает необходимость в ее отключении. Эта процедура не слишком сложная и многие смогут это легко повторить, ну а если отключение не дало желаемого эффекта, то DEP всегда можно снова активировать. Для большей наглядности, в конце статьи можно посмотреть видео, где все подробно показано.

Что такое функция DEP?

Основное предназначение функции DEP, это защита вашей системы от вредоносных приложений и других угроз, которые могут быть опасны для Windows. Но не надо думать, что это на подобии антивируса или брандмауэра. Нет, это совсем другая программа, работающая по иному принципу.

Обычно, если с DEP не наблюдается проблем в системе, лучше вообще не трогать эти настройки. Но в некоторых случаях, встроенная утилита может создавать помехи в работе вполне нормальных программ, которые не несут никакой угрозы. В таких случаях приходится прибегать к отключению этой функции.

Как отключить DEP в Windows?

Ну что же, приступим к делу. Откройте меню «Пуск» и в поисковом поле введите «cmd» (без кавычек). Появится список найденных файлов, в самом верху будет одноименная программа. Но не спешите ее запускать, ведь мы должны работать через учетную запись администратора. Поэтому, сделайте по ней клик правой кнопкой мышки и нажмите на «Запуск от имени администратора».

При этом, если находитесь в системе с учетной записи простого пользователя, то вам придется дополнительно ввести пароль для входа через учетную запись администратора, если он установлен.

После этих действий откроется окошко командной строки. Скопируйте в него данную команду и нажмите клавишу «Enter»: bcdedit.exe /set nx AlwaysOff

Чтобы все изменения начали работать, выполните перезагрузку компьютера. Вот так мы полностью выполнили отключение DEP для абсолютно всех приложений, служб и программ. Это действие применяется в любом случае, даже если работа этой функции никак не поддерживается на аппаратном уровне.

Выключаем DEP только для отдельного приложения

Есть и такой способ. Чтобы это сделать, откройте панель управления и перейдите в раздел «Система». В левой части окна, на панели, нажмите на ссылку «Дополнительных параметров системы».

На самой первой вкладке «Дополнительно» там, где раздел «Быстродействие», делаем клик по кнопке «Параметров».

В следующем окошке открываем вкладку «Предотвращение выполнения данных». Видим такую картинку.

При стандартных настройках, эта функция будет работать исключительно с основными программами и службами. Но если переместить переключатель на пункт ниже, туда где написано «Включить для всех программ и служб», у нас появится возможность выбрать и добавить к списку программы, с которыми DEP не будет работать. Просто выбираете в списке программу или нажимаете «Добавить» и через окно проводника найдите исполняемый файл программы и выбираете его.

Но есть одна особенность, 64 разрядные приложения не будут добавляться к данному списку. И далеко не все программы могут поддерживать работу без функции предотвращения выполнения данных. Это нужно учитывать и в таких случаях будет появляться ошибка.

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

Как включить DEP?

Чтобы снова запустить работу данной функции, откройте командную строку (cmd) с правами администратора, скопируйте туда и выполните вот такую команду:

bcdedit.exe /set nx OptIn

После этого сделайте перезагрузку компьютера и DEP будет работать, как и прежде. Напоследок, для большей наглядности, предлагаем вам взглянуть на видео, где все подробно показано:

В Microsoft проделали неплохую работу по повышению уровня безопасности, результаты которой появились в XP Service Pack 2. Описанная методика атаки не должна восприниматься как следствие того, что Microsoft не в состоянии делать что-то качественно и надежно, так как уступки в плане безопасности были сделаны для сохранения совместимости. Всегда есть компромисс между новыми системами защиты и потенциальными проблемами совместимости и нужно заметить, что возможно никто другой так не заботится о сохранении обратной совместимости своих продуктов, как Microsoft.

Обход аппаратной реализации DEP в Windows

Одним из самых значительных изменений, представленных Microsoft в Windows XP Service Pack 2 и Windows 2003 Server Service Pack 1, было поддержка новой возможности, названной Data Execution Prevention (DEP). Этот механизм позволяет делать именно то, что подразумевает его название: предотвращать выполнение кода в областях памяти не предназначенных для выполнения. Такая технология очень важна для предотвращения использования многих уязвимостей в программном обеспечении, так как большинство эксплойтов основано на хранении произвольного кода в областях памяти, не предназначенных для выполнения, например в стеке или куче.

DEP может работать в двух режимах. Первый режим называется Программный DEP (Software-enforced DEP) и обладает ограниченной функциональностью для предотвращения выполнения кода эксплойтов, использующих технику перезаписи SEH. Программный DEP используется на компьютерах, не имеющих поддержки неисполняемых страниц на аппаратном уровне. Кроме того, программная защита DEP встраивается во время компиляции, и поэтому работает только для системных библиотек и пересобранных с поддержкой DEP сторонних приложений. Способ обхода программного DEP был описан ранее и не будет обсуждаться в этой статье.

Второй режим работы DEP – аппаратный (Hardware-enforced DEP). Он используется в тех случаях, когда аппаратное обеспечение поддерживает неисполняемые страницы памяти. Большинство существующих процессоров intel-подобной архитектуры не поддерживают такую возможность (из-за унаследованной поддержки только страниц доступных на чтение или на запись), однако новые чипсеты начинают поддерживать неисполняемые страницы через технологии типа Page Address Extensions (PAE). Аппаратный DEP наиболее интересный режим, так как он действительно сильно затрудняет использование большинства методов атаки. В этой статье описана методика обхода DEP, работающего в аппаратном режиме.

Перед описанием методики, разумно будет определить некоторые понятия, которыми мы будем оперировать. В данном случае методика предназначена для обеспечения выполнения кода из области памяти, не предназначенной для исполнения, например стека потока или кучи процесса, при условии использования аппаратного DEP. Данная методика должна полностью нейтрализовывать DEP, так как при написании эксплойтов все еще используется прием исполнения произвольного кода из доступных на запись областей памяти. Кроме того, этот способ должен быть универсален, насколько это возможно, и без серьезных изменений должен работать и для существующих и для новых эксплойтов. Определившись с требованиями, самое время разобраться в новых возможностях, пришедших с аппаратным DEP.

Реализуя поддержку DEP, в Microsoft хорошо представляли, какое количество сторонних приложений может столкнуться с проблемой несовместимости из-за постановки под вопрос факта исполняемости той или иной области памяти. С учетом этого, DEP был спроектирован с возможностью настройки параметров его работы. По умолчанию защита включена только для системных процессов и либо для некоторых заранее определенных приложений (OptIn), либо для всех приложений, кроме заранее определенных (OptOut). Два этих флага передаются в ядро во время загрузки системы через опцию /NoExecute в файле boot.ini. Кроме того, в дополнение к NoExecute, в ядро могут быть переданы еще два флага - AlwaysOn или AlwaysOff. Два этих параметра устанавливают флаг использования или не использования DEP для каждого процесса, независимо от его настроек. В Windows XP SP2 по умолчанию используется OptIn, тогда как в Windows 2003 Server SP1 – OptOut.

Кроме использования глобального системного флага, существует возможность включить или отключить использование DEP для каждого процесса. Отключить поддержку NX (non-executable) можно во время выполнения процесса. Для этого, в ntdll.dll была добавлена функция LdrpCheckNXCompatibility, проверяющая некоторые условия и определяющая, нужно ли использовать поддержку NX для процесса. Эта функция вызывается каждый раз, когда какая-либо DLL загружается в контекст процесса, через функцию LdrpRunInitializationRoutines. Вначале проверяется, загружена ли SafeDisc DLL. Если да, NX не используется. Затем происходит анализ базы данных приложений, чтобы узнать, должна ли быть включена или отключена поддержка NX для процесса. И, наконец, проверяется, есть ли в DLL секции не совместимые с NX (такие как .aspack, .pcle, и .sforce).

По результатам этих проверок, поддержка NX или разрешается или не разрешается через новый PROCESSINFOCLASS, названный ProcessExecuteFlags (0x22). При вызове NtSetInformationProcess с этим параметром, в качестве дополнительного аргумента в функцию передается 4 байта битовой маски. Далее эта битовая маска передается в функцию nt!MmSetExecuteOptions, которая выполняет соответствующую операцию. В качестве части битовой маски можно передать параметр MEM_EXECUTE_OPTION_PERMANENT (0x8), означающий запрет на повторное изменение флагов исполнения. Для включения поддержки NX используется флаг MEM_EXECUTE_OPTION_DISABLE (0x1), для отключения - MEM_EXECUTE_OPTION_ENABLE (0x2). В зависимости от флагов процесса, выполнение кода из областей памяти, не предназначенных для исполнения, может быть разрешено (MEM_EXECUTE_OPTION_ENABLE) или запрещено (MEM_EXECUTE_OPTION_DISABLE).

Если бы можно было изменить флаги исполнения процесса, атакующий мог бы выполнять код из областей памяти ранее защищенных от исполнения. Чтобы осуществить это, атакующий должен иметь возможность выполнять код из областей памяти разрешенных для исполнения. Для этого могут пригодиться исполняемые области памяти, находящиеся по одним и тем же адресам в каждом процессе.

Чтобы использовать эту возможность в своих интересах, атакующий должен тем или иным способом вызвать функцию NtSetInformationProcess с параметром ProcessExecuteFlags. Кроме того, аргумент ProcessInformation должен иметь установленный бит MEM_EXECUTE_OPTION_ENABLE и обязательно сброшенный MEM_EXECUTE_OPTION_DISABLE. Следующий код демонстрирует вызов этой функции, результатом которого является отключение поддержки NX для вызывающего процесса:

Другой подход заключается в том, что атакующий может использовать код, уже находящийся в пространстве ntdll, с целью отключения поддержки NX для процесса. Вернувшись в определенный блок кода можно отключить поддержку NX при условии, что ntdll сможет вернуть управление в контролируемый атакующим буфер. Ограничением этого метода является то, атакующий должен контролировать стек, так же как при большинстве атак в стиле ret2libc, однако есть и плюс - нет надобности в контроле аргументов.

Вначале нужно переместить поток управления в область памяти, в которой находятся команды эквивалентные комбинации mov al, 0x1 / ret. Существует много примеров таких комбинаций команд: xor eax, eax/inc eax/ret; mov eax, 1/ret; и т.д. Один из таких примеров можно найти в функции ntdll!NtdllOkayToLockRoutine.

Эта команда устанавливает младший байт регистра eax в 1. Для чего это нужно, будет понятно далее. Как только поток управления перейдет к команде mov, а затем и ret, атакующий должен будет изменить стек таким образом, чтобы по команде ret произошел возврат в другой сегмент кода внутри ntdll. А точнее, должен произойти возврат в подпрограмму ntdll!LdrpCheckNXCompatibility.

В этом блоке кода проверяется, равен ли младший байт регистра eax единице. Независимо от результатов проверки, в регистр esi кладется значение 2. После этого проверяется, установлен ли zero-флаг (он будет установлен, если младший байт eax равен 1). Так как этот код будет выполнен после первого набора инструкций mov al, 0x1 / ret, флаг ZF будет установлен всегда, что вызовет передачу управления на адрес 0x7c93feba.

Здесь локальной переменной присваивается значение регистра esi, в данном случае 2. Далее поток выполнения переходит на адрес 0x7c91d403.

Этот блок кода, в свою очередь, сравнивает значение локальной переменной, равной 2, с нулем. Если переменная не равна нулю, происходит переход на адрес 0x7c935d6d.

С этого места становится интересней. Здесь происходит вызов NtSetInformationProcess с параметром ProcessExecuteFlags. Указатель на параметр ProcessInformation, ранее инициализированный значением 2, также передается в качестве дополнительного аргумента. Результатом этого будет отключение поддержки NX для процесса. После завершения работы функции ZwSetInformationProcess поток выполнения перейдет на адрес 0x7c91d441.

Здесь происходит восстановление сохраненных значений регистров, выполняется команда leave и возврат в вызывающую функцию. В данном случае атакующий изменяет фрейм стека таким образом, что команда ret осуществит переход на команду, которая, в свою очередь, перенаправит поток выполнения в контролируемый буфер, содержащий произвольный код, который теперь, когда поддержка NX отключена, будет выполнен.

Для реализации этой техники, нужно знать три адреса. Первый – это адрес комбинации mov al, 0x1 / ret или эквивалентной. К счастью, таких комбинаций много, хотя и не все такие простые, как та, что описана в этой статье. Второй – адрес начала блока кода cmp al, 0x1 внутри ntdll!LdrpCheckNXCompatibility. Если оба этих адреса находятся в пределах ntdll, эксплойт будет более переносимый, чем тот, который зависит от адресов в двух разных DLL. И, наконец, третий адрес, который использовался бы на машинах, не имеющих поддержки аппаратного DEP, команды jmp esp или подобной, в зависимости от рассматриваемой уязвимости.

Кроме перечисленных требований, описанная методика полагается на тот факт, что ebp указывает на доступный для записи адрес, чтобы переменная, показывающая, что поддержка NX должны быть отключена, могла быть временно сохранена. Это можно реализовать различными способами, поэтому данное требование не является сильно ограничивающим фактором.

Для тестирования техники, был модифицирован эксплойт warftpd_165_user из Metasploit Framework, написанный Fairuzan Roslan. Эксплойт использует простое переполнение стека. Да модификации он выглядел следующим образом:

Этот код создает массив размером 1024 байт, заполненный опкодами NOP. Начиная с 485 байта, записан 4-байтовый адрес возврата, указывающий на шелкод, добавленный в конец массива. В системе с включенной поддержкой аппаратного DEP, эксплойт терпит неудачу при попытке выполнения первой же команды NOP, находящейся в области памяти (стеке потока), не предназначенной для выполнения.

Применив описанную выше методику, эксплойт, а точнее структура отправляемого буфера, была модифицирована:

В нашем случае буфер заполняется 485 командами int3. Затем в буфер помещается адрес возврата, указывающий на ntdll!NtdllOkayToLockRoutine. Так как эта подпрограмма выполняет retn 0x4, следующие 4 байта являются подделанным аргументом, выталкивающимся из стека. Когда NtdllOkayToLockRoutine отработает, стек будет указывать на 493 байт буфера, который уже заранее проинициализирован (находится сразу за перезаписанным адресом возврата 0x7c952080 и подделанным аргументом). Это означает, что по завершению работы NtdllOkayToLockRoutine поток выполнения перейдет на адрес 0x7c91d3f8. Этот блок кода проверяет младший байт регистра eax и конечном счете приводит к отключению поддержки NX для процесса. После этого из стека выталкиваются сохраненные значения регистров и выполняется команда leave, присваивающая указателю стека значение, на которое в данный момент указывает регистр ebp. В данном случае, ebp на 0x54 байта был отдален от esp, поэтому мы вставили дополнительные 0x54 байта. После этого указатель стека указывает на 577 байт нашего буфера (сразу за дополнительными 0x54 байтами). Это означает, что произойдет возврат на любой адрес, находящийся в этом месте буфера. В данном конкретном случае, здесь должен находиться специфичный для каждой системы адрес команды jmp esp или эквивалентной. После выполнения команды jmp esp поток выполнения перейдет на шелкод. Когда отработает шелкод, эксплойт будет вести себя так, как будто не было никаких изменений:

Методика, описанная в этой статье, позволяет обойти защитный механизм, реализуемый аппаратным DEP в стандартных дистрибутивах Windows XP Service Pack 2 и Windows 2003 Server Service Pack 1. Недостаток защиты не связан с какой-нибудь определенной ошибкой, допущенной в процессе реализации поддержки аппаратного DEP, а является побочным эффектом архитектуры решения Microsoft для отключения поддержки NX для процесса режима пользователя из самого процесса. Если бы такой возможности не было, т.е. поддержку NX нельзя было бы отключить во время работы процесса из самого процесса, подходы, описанные в статье, не были бы применимы.

Не интересно описывать проблему, не предложив путей ее решения. Для противодействия атаке нужно выделить ряд вещей, от которых зависит ее успех. Первое и самое главное, описанный подход зависит от знания трех не связанных друг с другом адресов. Во-вторых, успех зависит от того, позволено ли процессу режима пользователя отключать поддержку NX самому себе. И, в-третьих, необходимо контролировать стек, чтобы иметь возможность выполнить атаку в стиле ret2libc.

Первое условие можно нарушить, реализовав механизм Случайного Размещения в Адресном Пространстве (Address Space Layout Randomization), который сделает неизвестным для атакующего расположение нужного блока кода. Второе условие нарушается путем вынесения программной логики контроля над включением/отключением поддержки NX для процесса в режим ядра, так чтобы нельзя было изменять эти параметры напрямую. Нужно пересмотреть сегодняшнею модель, в рамках которой можно отключить поддержку NX при возникновении некоторых событий (типа загрузки несовместимой с NX динамической библиотеки). Несмотря на неоднозначность данного решения, авторы рассматривают его с точки зрения совместимости и находят вполне пригодным. И, наконец, третье условие не относится к той сфере, которую Microsoft может контролировать. Кроме этих потенциальных решений, можно было бы сделать так, чтобы флаг поддержки NX устанавливался при инициализации процесса и был бы неизменен на протяжении всей его жизни. Хотя авторы не уверены насчет выполнимости такого решения с сохранением возможности отключения поддержки NX для несовместимых с этой технологий подгружаемых динамических библиотек.

В заключение, авторы хотели бы отметить, что в Microsoft проделали неплохую работу по повышению уровня безопасности, результаты которой появились в XP Service Pack 2. Описанная методика атаки не должна восприниматься как следствие того, что Microsoft не в состоянии делать что-то качественно и надежно, так как уступки в плане безопасности были сделаны для сохранения совместимости. Всегда есть компромисс между новыми системами защиты и потенциальными проблемами совместимости и нужно заметить, что возможно никто другой так не заботится о сохранении обратной совместимости своих продуктов, как Microsoft.

Установка и настройка Microsoft Windows Server 2003
для использования на локальном компьютере!

Неоценимый выигрыш — в возможности использовать память > 4ГБ (до 64 ГБ на WS2003 32bit Enterprise) и GPT (диски > 2 ТБ).

Microsoft Windows Server 2003 R2 — winextreme FAQ

Windows Server 2003 в Варезнике

Тема посвещенная обновлениям WS2003 здесь

Обзор установки WS2003 Подробнее.

Руководство по настройке Windows 2003 Server, как рабочей станции Подробнее.

Решение проблем с Мультимедиа и DirectX Подробнее.

Решение проблемы с установкой DirectX 9.0с на 2k3SP1 Подробнее.

затем применяем следующий патч реестра

пользователя с правами администратора при установке создал с помощью такого батника

1.Все серверные версии винды выходят после клиентских и в них не только серверные функции присутствуют, но и некоторые улучшения и исправления, кот. нет в клиентских (XP), потому как делаются они для предприятий и бизнеса.
2.Новая версия ядра системы, у XP 5.1, а у WS2003 5.2
3.WS2003 х32(х86) видит всю установленную оперативную память, в отличии от XP, который видит только 3.25Gb
Все остальные возможные пункты будут следовать уже из вышеперечисленных: это и лучшая безопасность и лучшая работа файловой системы и т. д.

Сравнить есть с чем: до ноября сидел 2 года на XP, пока не попалась сборка на базе Windows Server 2003, Enterprise Edition. Тоже ставил в качестве лучшей производительности в играх, что в итоге и получил (особенно заметно в графике, стали видны детали, не видные ранее на XP), на том же самом железе, в тех же самых играх. но уже на WS2003. С тех пор на компе 2 системы: WS2003 и WS2008.

Делайте выводы господа.

"Прежде чем читать дальше и устанавливать WS2003, следует четко уяснить, что никаких практических преимуществ по сравнению с Windows XP (со всеми имеющимися обновлениями) такая установка не дает - выигрыша в скорости и надежности не будет."

Неоценимый выигрыш - в возможности использовать память > 4ГБ (до 64 ГБ на WS2003 32bit Enterprise) и GPT (диски > 2 ТБ).

На самом деле, даже простая работа с файлами почему-то быстрее (проверено на чтении одной и той же директории с файлами сразу после загрузки системы: 2003 vs XP). Но особенно радикальное преимущество даёт файловый кэш, когда ему более не надобно ютиться в первых 3-х гигабайтах, и он может развернуться на всю установленную память (проверено на опыте).

Драйвера все поставились, которые на XP работали. Пара нефатальных неожиданностей была, но оказалась связана не собственно с WS2003, а с работой в режиме PAE с адресами > 3 ГБ
(эти особенности исчезают, если загрузиться с не-PAE ядром /KERNEL=. или же с помощью antiwpa.dll + tweaknt.exe 1.21 конвертировать сервер в Workstation, после чего он хотя и работает с PAE, но не более 3 ГБ - в точности как XP).

Насчёт Ramdisk за пределам 3 ГБ говорилось - именно так у меня и было. Вся проблема в том, что системный файловый кэш на XP ограничен 3 ГБ - он резко сужается при активном обмене с файлом подкачки - система не различает Ramdisk от обычного HDD и считает, что этот обмен - менее выгоден. Это главное. WS2003 может файлов на 8 ГБ целиком взять в кэш.

Программе > 2 ГБ не нужно, а нескольким программам - запросто (кодирование H.264 видео + ещё что-то - и с файлом подкачки XP тут всё резко замедлится).