Риски страниц памяти RWX

Question

Получив отрицательные комментарии к этому ответу - могу ли я реализовать счетчик в области .text без использования регистров? , я провел небольшое исследование, пытаясь понять, действительно ли страницы памяти RWX необычны и редкая вещь, или у каждой популярной программы есть некоторые. ( Наука! )

Я прикрепил к MSVS WinDBG, выполнил !address /f:Image,PAGE_EXECUTE_READWRITE,
и я видел много таких строк:

7a534000 7a537000     3000 MEM_IMAGE   MEM_COMMIT  PAGE_EXECUTE_READWRITE             Image "C:\WINDOWS\assembly\NativeImages_v2.0.50727_32\System\6836a951700c2eb01a933212425cda4e\System.ni.dll"

Я изучил его разделы, и есть раздел .xdata с флагами «Выполнить чтение-запись».

Означает ли это, что каждое приложение с загруженной в него библиотекой .NET имеет страницы памяти RWX?
Ваш браузер, например (если вы используете Windows). (К счастью, ни FF8, ни IE8 не используют .NET)

Так почему же нас беспокоит память RWX?

Answer 1

У меня такое чувство, что это, вероятно, не проблема. Вероятно, это требуется средой выполнения для поддержки динамического поведения.

Существует проблема безопасности с областями памяти, которые доступны как для записи, так и для выполнения. Это позволяет злоумышленнику заполнить буфер шеллкодом , а затем выполнить этот код. Заполнение буфера шеллкодом не имеет большого значения, это просто данные. Проблема возникает, когда злоумышленник может контролировать указатель инструкций (EIP), обычно путем повреждения фрейма стека функции с использованием переполнения буфера, основанного на стеке, а затем изменения потока выполнения путем присвоения этого указателя адресу шелл-кода (или где-то в сани NOP, который ударит шеллкод).

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