В компьютерной безопасности защита исполняемого пространства помечает области памяти как неисполняемые, так что попытка выполнить машинный код в этих регионах вызовет исключение . Он использует аппаратные функции, такие как бит 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 Enabler гарантирует, что эти ядра будут пытаться использовать бит 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. Для систем, в которых отсутствует аппаратное обеспечение NX, 32-битные ядра теперь обеспечивают аппроксимацию функции ЦП NX посредством программной эмуляции, которая может помочь заблокировать многие эксплойты, которые злоумышленник может запустить из стека или кучи памяти.
Функциональность невыполнения также присутствовала для других процессоров, отличных от 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 с пакетом обновления 2 (2004 г.) и Windows Server 2003 с пакетом обновления 1 (2005 г.), функции NX были впервые реализованы в архитектуре x86 . Защита исполняемого пространства в Windows называется «Предотвращением выполнения данных» (DEP).
В Windows XP или Server 2003 защита NX использовалась исключительно для критических служб Windows по умолчанию. Если процессор x86 аппаратно поддерживал эту функцию, то в Windows XP/Server 2003 функции NX включались автоматически по умолчанию. Если эта функция не поддерживалась процессором 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 ) посредством «Безопасной структурированной обработки исключений » Microsoft (SafeSEH). Для правильно скомпилированных приложений 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. Это нарушило методы старых эксплойтов, которые использовались для превращения программы в резидентное завершение и пребывание . Однако были быстро выпущены новые эксплойты для поддержки этой новой версии ядра, поскольку фундаментальная уязвимость в ядре Xbox не была затронута.
Если код пишется и выполняется во время выполнения ( ярким примером является JIT-компилятор) , то компилятор потенциально может использоваться для создания кода эксплойта (например, с использованием JIT Spray ), который помечен для выполнения и поэтому не будет перехвачен. [14] [15]
Программирование, ориентированное на возврат, может позволить злоумышленнику выполнить произвольный код, даже если применяется защита исполняемого пространства.