В компьютерной безопасности защита исполняемого пространства помечает области памяти как неисполняемые, так что попытка выполнить машинный код в этих областях вызовет исключение . Она использует аппаратные функции, такие как бит NX (бит невыполнения), или в некоторых случаях программную эмуляцию этих функций. Однако технологии, которые эмулируют или предоставляют бит NX, обычно налагают измеримые накладные расходы, в то время как использование аппаратно предоставляемого бита NX не налагает измеримых накладных расходов.
Burroughs 5000 предлагал аппаратную поддержку защиты исполняемого пространства при своем появлении в 1961 году; эта возможность оставалась в его преемниках по крайней мере до 2006 года. В его реализации маркированной архитектуры каждое слово памяти имело связанный с ним скрытый бит тега, обозначающий его код или данные. Таким образом, пользовательские программы не могли записывать или даже читать программное слово, а слова данных не могли быть выполнены.
Если операционная система может пометить некоторые или все записываемые области памяти как неисполняемые, она может предотвратить выполнение областей памяти стека и кучи . Это помогает предотвратить успешное выполнение некоторых эксплойтов переполнения буфера , особенно тех, которые внедряют и выполняют код, например, червей Sasser и Blaster . Эти атаки основаны на том, что некоторая часть памяти, обычно стек, является как записываемой, так и исполняемой; если это не так, атака не удается.
Многие операционные системы реализуют или имеют доступную политику защиты исполняемого пространства. Вот список таких систем в алфавитном порядке, каждая из которых имеет технологии, упорядоченные от самых новых к самым старым.
Для некоторых технологий есть сводка, которая дает основные функции, поддерживаемые каждой технологией. Сводка структурирована следующим образом.
Технология, обеспечивающая архитектурно-независимую эмуляцию , будет функционировать на всех процессорах, которые не поддерживаются аппаратно. Строка "Другие поддерживаемые" предназначена для процессоров, которые допускают некий метод серой зоны, где явный бит NX не существует, но аппаратно позволяет эмулировать его каким-либо образом.
Начиная с Android 2.3 и более поздних версий, архитектуры, которые поддерживают эту функцию, по умолчанию имеют неисполняемые страницы, включая неисполняемый стек и кучу. [1] [2] [3]
Первоначальная поддержка бита NX на процессорах x86-64 и IA-32 , которые его поддерживают, впервые появилась в FreeBSD -CURRENT 8 июня 2004 года. Она присутствует в выпусках FreeBSD, начиная с версии 5.3.
Ядро Linux поддерживает бит NX на процессорах x86-64 и IA-32 , которые его поддерживают, например, на современных 64-битных процессорах производства AMD, Intel, Transmeta и VIA. Поддержка этой функции в 64-битном режиме на процессорах x86-64 была добавлена в 2004 году Энди Клин, а позднее в том же году Инго Молнар добавил поддержку в 32-битном режиме на 64-битных процессорах. Эти функции стали частью основной ветки ядра Linux с момента выпуска версии ядра 2.6.8 в августе 2004 года. [4]
Наличие бита NX в 32-разрядных ядрах x86, которые могут работать как на 32-разрядных процессорах x86, так и на 64-разрядных процессорах, совместимых с IA-32, имеет важное значение, поскольку 32-разрядное ядро x86 обычно не ожидает бита NX, который предоставляют AMD64 или IA-64 ; патч включения NX гарантирует, что эти ядра попытаются использовать бит NX, если он присутствует.
Некоторые дистрибутивы Linux для настольных ПК , такие как Fedora , Ubuntu и openSUSE , по умолчанию не включают опцию HIGHMEM64 в своих ядрах по умолчанию, которая требуется для получения доступа к биту NX в 32-битном режиме, поскольку режим PAE , необходимый для использования бита NX, вызывает сбои загрузки на процессорах до Pentium Pro (включая Pentium MMX) и Celeron M и Pentium M без поддержки NX. Другие процессоры, которые не поддерживают PAE, — это AMD K6 и более ранние, Transmeta Crusoe , VIA C3 и более ранние, а также Geode GX и LX. Версии VMware Workstation старше 4.0, версии Parallels Workstation старше 4.0, а также Microsoft Virtual PC и Virtual Server не поддерживают PAE на гостевой ОС. Fedora Core 6 и Ubuntu 9.10 и более поздние версии предоставляют пакет kernel-PAE, который поддерживает PAE и NX.
Защита памяти NX всегда была доступна в Ubuntu для любых систем, которые имели аппаратное обеспечение для ее поддержки и работали с 64-битным ядром или 32-битным серверным ядром. 32-битное ядро рабочего стола PAE (linux-image-generic-pae) в Ubuntu 9.10 и более поздних версиях также предоставляет режим PAE, необходимый для оборудования с функцией NX CPU. Для систем, в которых отсутствует оборудование NX, 32-битные ядра теперь предоставляют приближение функции NX CPU через программную эмуляцию, которая может помочь заблокировать множество эксплойтов, которые злоумышленник может запустить из стека или кучи памяти.
Функциональность non-execute также присутствовала и для других процессоров, отличных от x86, поддерживающих эту функциональность во многих выпусках.
Разработчик ядра Red Hat Инго Молнар выпустил патч ядра Linux под названием Exec Shield для аппроксимации и использования функциональности NX на 32-разрядных процессорах x86. Исправление Exec Shield было выпущено в список рассылки ядра Linux 2 мая 2003 года, но было отклонено для слияния с базовым ядром, поскольку оно включало некоторые навязчивые изменения в коде ядра для обработки сложных частей эмуляции. Устаревшая поддержка процессоров Exec Shield аппроксимирует эмуляцию NX, отслеживая верхний предел сегмента кода. Это накладывает всего несколько циклов накладных расходов во время переключений контекста, что для всех намерений и целей неизмеримо. Для устаревших процессоров без бита NX Exec Shield не может защитить страницы ниже предела сегмента кода; вызов mprotect() для маркировки более высокой памяти, такой как стек, исполняемым также пометит всю память ниже этого предела исполняемым. Таким образом, в этих ситуациях схемы Exec Shield терпят неудачу. Это цена низких накладных расходов Exec Shield. Exec Shield проверяет наличие двух маркировок заголовков ELF , которые определяют, должны ли стек или куча быть исполняемыми. Они называются PT_GNU_STACK и PT_GNU_HEAP соответственно. Exec Shield позволяет устанавливать эти элементы управления как для двоичных исполняемых файлов, так и для библиотек; если исполняемый файл загружает библиотеку, требующую ослабления данного ограничения, исполняемый файл унаследует эту маркировку и ослабит это ограничение.
Технология PaX NX может эмулировать функциональность NX или использовать аппаратный бит NX. PaX работает на процессорах x86, не имеющих бита NX, например, 32-битных x86. Ядро Linux все еще не поставляется с PaX (по состоянию на май 2007 г.); патч должен быть объединен вручную.
PaX предоставляет два метода эмуляции бита NX, называемые SEGMEXEC и PAGEEXEC. Метод SEGMEXEC налагает измеримые, но низкие накладные расходы, обычно менее 1%, что является постоянным скаляром, возникающим из-за зеркалирования виртуальной памяти, используемого для разделения между выполнением и доступом к данным. [5] SEGMEXEC также имеет эффект сокращения вдвое виртуального адресного пространства задачи, позволяя задаче получать доступ к меньшему объему памяти, чем она могла бы получить обычно. Это не является проблемой, пока задача не требует доступа к более чем половине обычного адресного пространства, что случается редко. SEGMEXEC не заставляет программы использовать больше системной памяти (т. е. ОЗУ), он только ограничивает то, к чему они могут получить доступ. На 32-разрядных процессорах это становится 1,5 ГБ вместо 3 ГБ.
PaX предоставляет метод, аналогичный приближению Exec Shield в PAGEEXEC в качестве ускорения; однако, когда большая память помечена как исполняемая, этот метод теряет свою защиту. В этих случаях PaX возвращается к старому методу с переменными накладными расходами, используемому PAGEEXEC для защиты страниц ниже предела CS, что может стать довольно высоконакладной операцией в определенных шаблонах доступа к памяти . Когда метод PAGEEXEC используется на ЦП, предоставляющем аппаратный бит NX, используется аппаратный бит NX, таким образом, не возникает никаких существенных накладных расходов.
PaX предоставляет ограничения mprotect(), чтобы не дать программам помечать память способами, которые делают память полезной для потенциального эксплойта . Эта политика приводит к тому, что некоторые приложения перестают работать, но ее можно отключить для затронутых программ.
PaX позволяет индивидуально управлять следующими функциями технологии для каждого исполняемого двоичного файла:
PaX игнорирует как PT_GNU_STACK, так и PT_GNU_HEAP. В прошлом PaX имел опцию конфигурации для соблюдения этих настроек, но эта опция была удалена по соображениям безопасности, так как она считалась бесполезной. Те же результаты PT_GNU_STACK обычно могут быть достигнуты путем отключения ограничений mprotect(), поскольку программа обычно mprotect() стека при загрузке. Это может быть не всегда так; в ситуациях, когда это не удается, простое отключение PAGEEXEC и SEGMEXEC эффективно снимет все ограничения исполняемого пространства, предоставляя задаче ту же защиту в исполняемом пространстве, что и не-PaX система.
macOS для Intel поддерживает бит NX на всех процессорах, поддерживаемых Apple (начиная с Mac OS X 10.4.4 — первого релиза Intel — и далее). Mac OS X 10.4 поддерживала только защиту стека NX. В Mac OS X 10.5 все 64-битные исполняемые файлы имеют стек и кучу NX; защиту W^X. Сюда входят x86-64 (Core 2 или более поздние версии) и 64-битный PowerPC на компьютерах Mac G5 .
Начиная с NetBSD 2.0 и более поздних версий (9 декабря 2004 г.), архитектуры, которые его поддерживают, имеют неисполняемые стек и кучу. [6]
Архитектуры с постраничной детализацией включают: alpha , amd64 , hppa , i386 (с PAE ), powerpc (ibm4xx), sh5 , sparc ( sun4m , sun4d ), sparc64.
Архитектуры, которые могут поддерживать только региональную детализацию: i386 (без PAE), другие powerpc (например, macppc).
Другие архитектуры не используют преимущества неисполняемого стека или кучи; NetBSD по умолчанию не использует какую-либо программную эмуляцию для предоставления этих функций на этих архитектурах.
Технология в операционной системе OpenBSD , известная как W^X, помечает записываемые страницы по умолчанию как неисполняемые на процессорах, которые это поддерживают. На 32-битных процессорах x86 сегмент кода настроен на включение только части адресного пространства, чтобы обеспечить некоторый уровень защиты исполняемого пространства.
OpenBSD 3.3 вышла 1 мая 2003 года и стала первой версией, включающей W^X.
Solaris поддерживает глобальное отключение выполнения стека на процессорах SPARC, начиная с Solaris 2.6 (1997); в Solaris 9 (2002) была добавлена поддержка отключения выполнения стека для каждого исполняемого файла.
Первая реализация неисполняемого стека для Windows (NT 4.0, 2000 и XP) была опубликована SecureWave через свой продукт SecureStack в 2001 году на основе работы PaX [7] [8]
Начиная с Windows XP Service Pack 2 (2004) и Windows Server 2003 Service Pack 1 (2005), функции NX были впервые реализованы на архитектуре x86 . Защита исполняемого пространства в Windows называется «Data Execution Prevention» (DEP).
В Windows XP или Server 2003 защита NX использовалась исключительно на критических службах Windows по умолчанию. Если процессор x86 поддерживал эту функцию на аппаратном уровне, то функции NX автоматически включались в Windows XP/Server 2003 по умолчанию. Если функция не поддерживалась процессором x86, то защита не предоставлялась.
Ранние реализации DEP не предусматривали рандомизацию адресного пространства (ASLR), что допускало потенциальные атаки с возвратом в libc , которые могли быть использованы для отключения DEP во время атаки. [9] В документации PaX подробно описывается, почему необходим ASLR; [10] было создано доказательство концепции, подробно описывающее метод, с помощью которого DEP можно обойти при отсутствии ASLR. [11] Возможно, удастся разработать успешную атаку, если злоумышленник узнает адрес подготовленных данных, таких как поврежденные изображения или MP3-файлы .
Microsoft добавила функциональность ASLR в Windows Vista и Windows Server 2008. На этой платформе DEP реализован посредством автоматического использования ядра PAE в 32-разрядной Windows и собственной поддержки в 64-разрядных ядрах. Windows Vista DEP работает, отмечая определенные части памяти как предназначенные только для хранения данных, которые процессор с поддержкой битов NX или XD затем понимает как неисполняемые. [12] В Windows, начиная с версии Vista, включен или отключен DEP для определенного процесса, можно просмотреть на вкладке Процессы/Сведения в Диспетчере задач Windows .
Windows реализует программное DEP (без использования бита NX ) через "Safe Structured Exception Handling " (SafeSEH) от Microsoft . Для правильно скомпилированных приложений SafeSEH проверяет, что при возникновении исключения во время выполнения программы обработчик исключения является тем, который определен приложением, как оно было изначально скомпилировано. Эффект этой защиты заключается в том, что злоумышленник не может добавить свой собственный обработчик исключений, который он сохранил на странице данных через непроверенный программный ввод. [12] [13]
Если поддерживается NX, он включен по умолчанию. Windows позволяет программам контролировать, какие страницы запрещают выполнение через свой API , а также через заголовки разделов в PE-файле . В API доступ к биту NX во время выполнения предоставляется через вызовы Win32 API VirtualAlloc[Ex] и VirtualProtect[Ex] . Каждая страница может быть индивидуально помечена как исполняемая или неисполняемая. Несмотря на отсутствие предыдущей аппаратной поддержки x86, с самого начала предоставлялись как исполняемые, так и неисполняемые параметры страниц. На процессорах до NX наличие атрибута «исполняемый» не имеет никакого эффекта. Он был задокументирован так, как будто он функционировал, и, как следствие, большинство программистов использовали его правильно. В формате PE-файла каждый раздел может указывать свою исполняемость. Флаг выполнения существовал с самого начала формата, и стандартные компоновщики всегда правильно использовали этот флаг, даже задолго до бита NX. Благодаря этому Windows может принудительно применять бит NX в старых программах. Если предположить, что программист следовал "лучшим практикам", приложения должны работать правильно теперь, когда NX фактически применяется. Только в нескольких случаях возникали проблемы; собственный .NET Runtime от Microsoft имел проблемы с битом NX и был обновлен.
В Xbox от Microsoft , хотя процессор не имеет бита NX, более новые версии XDK устанавливают ограничение сегмента кода в начале раздела .data ядра (после этой точки в обычных обстоятельствах не должно быть никакого кода). Начиная с версии 51xx, это изменение было также внедрено в ядро новых Xbox. Это сломало методы, которые старые эксплойты использовали для того, чтобы стать программой terminate-and-stay-resident . Однако новые эксплойты были быстро выпущены для поддержки этой новой версии ядра, поскольку фундаментальная уязвимость в ядре Xbox не была затронута.
Если код пишется и выполняется во время выполнения ( ярким примером является JIT-компилятор ), то компилятор потенциально может использоваться для создания кода эксплойта (например, с помощью JIT Spray ), который был помечен для выполнения и, следовательно, не будет перехвачен. [14] [15]
Возвратно-ориентированное программирование может позволить злоумышленнику выполнить произвольный код, даже если включена защита исполняемого пространства.