2.2. Проект pax

Целью проекта РаХ является также создание механизма, позво­ляющего противостоять атакам, основанным на различных способах пе­рехвата управления у нормально исполняющегося процесса. Перечень за­щит, предоставляемых РаХ-ядром, значительно отличается от аналогично­го перечня Opemwall-ядра. РаХ предоставляет более широкий выбор меха­низмов, реализующих контроль попыток вживления вредоносного кода в исполняющийся процесс, исполнения существующего программного кода в порядке, не предусмотренном изначальным алгоритмом программы и об­работку процессом некорректных данных, поступающих извне. Вместе с тем, в нем нет механизмов, ограничивающих доступ к символьным ссыл­кам, и не осуществляется контроль ситуаций, связанных с перерасходом системных ресурсов, выделенных процессу. PaX был впервые выпущен в 2000 году. PaX был написан одноимённой командой разработчиков. Основатель PaX в настоящее время предпочитает оставаться анонимным по неизвестным общественности причинам.

PaX помечает сегмент данных программ в памяти как недоступный для исполнения (так как он по определению не может содержать программных директив, которые необходимо выполнить), а сегмент кода — как не перезаписываемый, и, в придачу, при каждом запросе выделяет память программе из произвольных мест. Эта методика эффективна против применения различных эксплоитов, использующих, например, уязвимость, основанную на переполнении буфера памяти. Такая защита изначально полностью предотвращает прямое выполнение кода из памяти, и одновременно, с прикладной точки зрения, делает, так называемые, return-to-libc (ret2libc) атаки сложными для выполнения (они становятся выполняемыми скорее наудачу, без заранее предсказуемого результата). Однако, вместе с тем, PaX не предотвращает ошибки, приводящие к возможности переопределения переменных и значений указателей.

Довольно большая часть от общего числа уязвимостей в компьютерных системах вызвана ошибками в программах, которые допускают возможность переопределять свои функции, переписывая их «на лету» (напрямую в оперативной памяти). Принцип работы многих червей, вирусов, а также многочисленные методики непосредственных попыток взлома систем основаны на изменении содержимого памяти внедрением с последующим выполнением вредоносного кода, на исполнении части содержимого области памяти через умышленное изменение указателей и т. п. Если подобные действия заблокировать каким-либо образом, то общий ущерб становится довольно незначительным, или его может не быть вовсе, даже если вирус и проник в систему. К тому же, многие черви (например, такие как Sasser) в этом случае не смогут внедриться в систему вообще.

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

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

Многие (но конечно далеко не все) ошибки разработчиков приводят к неправильному обращению их программ к памяти. Это предоставляет гипотетическую возможность заставить программу выполнять то, что она не должна делать по замыслу (например выдавать привилегированный шелл). Цель PaX — не нахождение и исправление подобных уязвимостей, а, скорее, предотвращение их использования атакующими приложениями. Последствия ошибок будут сведены к минимуму — выполнение программы будет попросту прервано, что с точки зрения PaX лучше, чем её скомпрометированный функционал.

Следует понимать, что PaX напрямую не предотвращает переполнение буфера, а лишь пытается эффективно пресечь потенциальные, связанные с ним, ошибки разработчиков, которые могут привести, например, к предоставлению непредусмотренного доступа к системе. Однако, существуют такие разработки, как Stack-Smashing Protector и StackGuard, которые пытаются определить именно само переполнение буфера и остановить выполнение компрометирующих систему программ. Такая методика называется stack-smashing protection. Она ориентирована на непосредственное блокирование прямых атак, в случае, если это возможно. Хотя и PaX, и stack-smashing protection, по сути, преследуют одну цель, они не взаимозаменяемы. Однако, внедрение обеих технологий, безусловно, сделает систему более защищённой. Некоторые дистрибутивы Linux уже имеют в своём составе оба компонента сразу (PaX и Stack Smash Protection).

По состоянию на данный момент, PaX еще не включён в основную ветку ядра, так как разработчики патча полагают, что он все ещё недостаточно готов. Но, несмотря на то, что PaX успешно используется на многих архитектурах, он всё ещё остаётся лишь частично, или вообще не поддерживаемым, в ряде других. Так PaX успешно применяется на IA-32 (x86), AMD64, IA-64, Alpha, PA-RISC, 32 и 64 bit MIPS, PowerPC и SPARC.