Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску
Эта статья посвящена патчу безопасности ядра Linux. Для использования в других целях, см Пакс (значения) .
Информацию об утилите архивирования см. В разделе pax (команда) .
У PaX есть своя собственная версия Tux , талисмана Linux .

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

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

PaX поддерживается командой PaX , основной кодер которой анонимен. Проект grsecurity включает PaX вместе с другими патчами ядра Linux, уникальными для grsecurity. Все более новые версии PaX, начиная с 2014 года, можно найти только как часть набора исправлений grsecurity.

Значение [ править ]

Различные типы компьютерной небезопасности вызваны ошибками в программах, которые позволяют изменять их функции, эффективно позволяя их «переписывать» во время работы. Первые 44 уведомления о безопасности, выпущенные Ubuntu, можно разделить на категории [1], чтобы показать, что 41% уязвимостей связаны с переполнением буфера, 11% - с переполнением целых чисел и 16% - с другой неправильной обработкой искаженных данных. Эти типы ошибок часто открывают возможность внедрить и выполнить внешний код или выполнить существующий код не по порядку, и составляют 61% выборочной группы, исключая перекрытие. (Это грубый анализ; более полный анализ отдельных уязвимостей, вероятно, даст очень разные цифры.) Многие черви , вирусы, и попытки взять на себя управление машиной полагаются на изменение содержимого памяти, так что вредоносный код выполняется; или при выполнении содержимого "данных" по неверному адресу. Если выполнение такой вредоносной программы может быть заблокировано, она может нанести небольшой или даже нулевой ущерб даже после установки на компьютер; многие из них, например червь Sasser , можно вообще предотвратить.

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

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

Многие, но не все ошибки программирования вызывают повреждение памяти. Из тех, которые работают и запускаются по намерению, некоторые позволят побудить программу выполнять различные действия, для которых она не предназначена, например, создание оболочки с высокими привилегиями. PaX фокусируется не на поиске и исправлении таких ошибок, а скорее на предотвращении и сдерживании методов эксплойтов, которые могут возникнуть из-за такой ошибки программиста. Подмножество из этих ошибок будет уменьшено по степени тяжести; программы прекращают работу, а не предоставляют услуги ненадлежащим образом.

PaX не предотвращает напрямую переполнение буфера; вместо этого он эффективно предотвращает использование многих из этих и связанных с ними программных ошибок для получения несанкционированного доступа в компьютерную систему. Другие системы, такие как Stack-Smashing Protector и StackGuard, действительно пытаются напрямую обнаруживать переполнение буфера и уничтожать вредоносную программу при обнаружении; этот подход называется защитой от разбивания стека , и он пытается заблокировать такие атаки до того, как они могут быть выполнены. С другой стороны, более общий подход PaX предотвращает повреждение после начала попытки. Хотя оба подхода позволяют достичь одних и тех же целей, они не являются полностью избыточными. Следовательно, использование обоих, в принципе, сделает операционную систему более безопасной.

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

Ограничения [ править ]

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

Документация по PaX [2], размещенная на веб-сайте PaX, описывает три класса атак, от которых PaX пытается защитить. В документации обсуждаются как атаки, от которых PaX будет эффективно защищать систему, так и те, от которых не будет. Все предполагают наличие полной, независимой от позиции исполняемой базы с полной защитой исполняемого пространства и полной рандомизацией макета адресного пространства. Вкратце, блокируемые атаки:

  1. Те, которые вводят и исполняют произвольный код. Эти типы атак часто включают шеллкод.
  2. Те, которые пытаются выполнить существующий программный код в исходном порядке, заданном программистом (ами). Это обычно называется атакой возврата к libc или для краткости ret2libc.
  3. Те, которые пытаются выполнить существующий программный код в намеченном порядке с произвольными данными. Эта проблема существовала в версиях zlib до 1.1.4 - поврежденный сжатый поток мог вызвать двойное освобождение.

Поскольку PaX нацелен на предотвращение ущерба от атак определенных типов, а не на поиск и исправление ошибок, которые разрешают их, он не может защитить от всех видов атак; действительно, предотвратить все атаки невозможно .

Первый класс атак все еще возможен со 100% надежностью, несмотря на использование PaX, если злоумышленнику не нужно заранее знать адреса в атакуемой задаче.

Второй и третий классы атак также возможны со 100% надежностью, если злоумышленнику необходимо заранее знать структуру адресного пространства и он может получить эти сведения, прочитав адресное пространство атакуемой задачи. Это возможно, если у цели есть ошибка, которая приводит к утечке информации, например, если злоумышленник имеет доступ к / proc / (pid) / maps. Существует патч неясности, который исключает NULL значения для диапазонов адресов и inodes в каждом источнике информации, доступном из пользовательского пространства, чтобы закрыть большинство этих дыр; однако в настоящее время он не включен в PaX.

Второй и третий классы атак возможны с небольшой вероятностью, если злоумышленнику необходимо заранее знать структуру адресного пространства, но он не может получить эти сведения, не прибегая к угадыванию или перебору. Документация ASLR [3] описывает, как можно в дальнейшем количественно оценить «небольшую вероятность» успеха этих атак.

Первый класс атак возможен, если злоумышленник может заставить атакуемую задачу создать, записать и mmap () файл. Это, в свою очередь, требует, чтобы был возможен второй метод атаки, поэтому его анализ применим и здесь. Хотя он не является частью PaX, среди прочего рекомендуется, чтобы производственные системы использовали систему контроля доступа, предотвращающую этот тип атак.

Ответственное системное администрирование по-прежнему требуется даже в системах PaXified. PaX предотвращает или блокирует атаки, использующие ошибки повреждения памяти , например, приводящие к атакам шеллкода и ret2libc. Большинство атак, которые может предотвратить PaX, связаны с ошибками переполнения буфера. В эту группу входят наиболее распространенные схемы, используемые для использования проблем управления памятью. Тем не менее, PaX не может предотвратить все такие атаки.

Особенности [ править ]

PaX предлагает защиту исполняемого пространства , используя (или эмулируя в программном обеспечении операционной системы) функциональность бита NX (то есть, встроенный ЦП и поддержку MMU для маркировки привилегий выполнения содержимого памяти). Он также обеспечивает рандомизацию разметки адресного пространства для защиты от атак ret2libc и всех других атак, основанных на известной структуре виртуальной памяти программы .

Защита исполняемого пространства [ править ]

Рис. 1 Сегменты памяти в программе. Синие сегменты - это код, зеленые - данные.

Основная особенность PaX - это предлагаемая им защита исполняемого пространства . Эти средства защиты используют бит NX на некоторых процессорах для предотвращения выполнения произвольного кода. Это предотвращает атаки, связанные с внедрением кода или шеллкодом. На процессорах IA-32, где нет бита NX, PaX может имитировать его функциональность различными способами.

Многие операционные системы, включая Linux, используют преимущества существующей аппаратной функциональности NX для применения соответствующих ограничений к памяти. На рис. 1 показан простой набор сегментов памяти в программе с одной загруженной библиотекой; зеленые сегменты - данные, а синие - код. В обычных случаях адресное пространство на AMD64 и других подобных процессорах по умолчанию будет больше похоже на рис. 1 с четко определенными данными и кодом. К сожалению, Linux по умолчанию не запрещает приложению изменять какие-либо средства защиты памяти; любая программа может создавать путаницу между данными и кодом , отмечая области кода как доступные для записи, а области данных как исполняемые. PaX предотвращает такие изменения, а также гарантирует наиболее строгий набор по умолчанию, подходящий для типичной работы.

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

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

Команде PaX пришлось принять некоторые дизайнерские решения относительно того, как обрабатывать системный вызов mmap () . Эта функция используется либо для отображения разделяемой памяти , либо для загрузки разделяемых библиотек. Из-за этого ему необходимо предоставить доступную для записи или исполняемую RAM, в зависимости от условий, в которых он используется.

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

Принудительные неисполняемые страницы [ править ]

По умолчанию Linux не обеспечивает наиболее безопасное использование неисполняемых страниц памяти с помощью бита NX. Более того, некоторые архитектуры даже не предоставляют явно способ пометки страниц памяти как неисполняемые. PaX предоставляет политику для максимально безопасного использования неисполняемых страниц.

Кроме того, если ЦП не предоставляет явный бит NX, PaX может имитировать (предоставить) бит NX одним из нескольких методов. Это снижает производительность системы, но значительно повышает безопасность. Кроме того, потеря производительности в некоторых методах может быть достаточно низкой, чтобы ее можно было игнорировать.

PAGEEXEC [ править ]

PAGEEXEC использует или эмулирует бит NX. На процессорах, не поддерживающих аппаратное обеспечение NX, каждой странице дается эмулируемый бит NX. Используемый для этого метод основан на архитектуре ЦП. Если доступен аппаратный бит NX, PAGEEXEC будет использовать его вместо его эмуляции, не неся затрат на производительность.

В архитектурах IA-32 битовая эмуляция NX выполняется путем изменения уровня разрешений неисполняемых страниц. Supervisor бит перегружен для представления NX. Это вызывает ошибку защиты , когда доступ происходит на страницу , и она еще не кэшируется в буфере перевод ассоциативного . В этом случае блок управления памятью предупреждает операционную систему; на IA-32 MMU обычно имеет отдельные кэши TLB для выполнения (ITLB) и чтения / записи (DTLB), поэтому эта ошибка также позволяет Linux и PaX определить, пыталась ли программа выполнить страницу как код. Если обнаружена ошибка ITLB, процесс завершается [ пояснить ]; в противном случае Linux принудительно разрешает загрузку DTLB, и выполнение продолжается в обычном режиме.

PAGEEXEC имеет то преимущество, что не делит адресное пространство памяти пополам; каждая задача по-прежнему получает виртуальное пространство RAM объемом 3 ГБ, а не разделение на 1,5 / 1,5. Однако для эмуляции он медленнее, чем SEGMEXEC, и в некоторых случаях вызывал серьезный ущерб производительности .

С мая 2004 года новый код PAGEEXEC для IA-32 в PaX отслеживает самую высокую исполняемую страницу в виртуальной памяти и отмечает все более высокие страницы как пользовательские. Это позволяет обрабатывать страницы данных, превышающие этот предел, такие как стек, как обычно, без потери производительности. Все, что находится ниже этой области, по-прежнему обрабатывается, как и раньше. Это изменение похоже на реализацию Exec Shield NX и реализацию OpenBSD W ^ X ; за исключением того, что PaX использует метод перегрузки битов Supervisor также для обработки страниц NX в сегменте кода.

SEGMEXEC [ править ]

SEGMEXEC эмулирует функциональность бита NX на процессорах IA-32 (x86), разделяя адресное пространство пополам и зеркально отображая сопоставления кода в адресном пространстве. Когда есть выборка инструкции , выборка транслируется через разделение. Если код там не отображается, программа уничтожается.

SEGMEXEC вдвое сокращает объем виртуальной памяти задачи. В нормальных условиях программы получают пространство виртуальной машины шириной 3 ГБ, в которое отображается физическая память . Под SEGMEXEC это становится разделением 1,5 / 1,5 ГиБ, при этом верхняя половина используется для зеркалирования. Несмотря на это, он увеличивает производительность, если эмуляция должна выполняться на архитектурах IA-32 (x86). Отображение в верхней и нижней половине пространства памяти связано с одной и той же страницей физической памяти, поэтому использование ОЗУ не увеличивается вдвое.

Ограниченный mprotect () [ править ]

Предполагается, что PaX гарантирует, что ОЗУ не будет одновременно записываемым и исполняемым. Одна из функций, mprotect (), изменяет права доступа к области памяти. UNIX Specification Single определяет mprotect () со следующей нотой в его описании:

Если реализация не может поддерживать комбинацию типов доступа, указанных в prot, вызов mprotect () завершится ошибкой.

Реализация PaX не позволяет странице памяти иметь разрешения PROT_WRITE и PROT_EXEC, когда включены ограничения mprotect () для задачи; любой вызов mprotect () для одновременной установки обоих (PROT_WRITE | PROT_EXEC) завершится ошибкой из-за EACCESS (Permission Denied). Это гарантирует, что страницы не станут одновременно доступными для записи и исполняемыми, и, таким образом, станет благодатной почвой для простых атак путем внедрения кода.

Подобный сбой происходит, если mprotect (... | PROT_EXEC) встречается на странице, на которой уже не установлено ограничение PROT_EXEC. Провал здесь оправдан; если на странице PROT_WRITE был внедрен код, а затем был сделан PROT_EXEC, более поздний повторный запуск эксплойта, разрешающий внедрение кода, позволит выполнить код. Без этого ограничения возможен трехэтапный эксплойт: внедрение кода, ret2libc :: ret2mprotect (), выполнение кода.

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

Эмуляция батута [ править ]

Батуты обычно реализуются gcc в виде небольших фрагментов кода, генерируемых во время выполнения в стеке . Таким образом, они требуют выполнения памяти в стеке, что запускает PaX, чтобы убить программу.

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

Рандомизация разметки адресного пространства [ править ]

См. Также: Рандомизация компоновки адресного пространства ядра

Рандомизация разметки адресного пространства или ASLR - это метод противодействия произвольному выполнению кода или атакам ret2libc. Эти атаки включают выполнение уже существующего кода в неправильном порядке, заданном программистом .

Рис. 2 Расстояние между различными областями памяти выбирается случайным образом, обозначается стрелкой на полпути. Например, промежуток между стеком и вершиной памяти имеет случайную величину.

ASLR, предоставляемый в PaX, при включении перемешивает базу стека и базу кучи в виртуальной памяти. Он также может произвольно рандомизировать базу mmap () и исполняемую базу программ. Это существенно снижает вероятность успешной атаки, поскольку атакующему коду требуется угадывать расположение этих областей.

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

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

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

PaX оставляет часть адресов, MSB , вне вычислений рандомизации. Это помогает гарантировать, что стек и куча размещены так, чтобы они не сталкивались друг с другом, а библиотеки размещены так, чтобы стек и куча не сталкивались с ними.

Эффект рандомизации зависит от процессора. 32-битные процессоры будут иметь 32 бита виртуального адресного пространства, что обеспечит доступ к 4 ГБ памяти. Поскольку Linux использует верхний 1 ГБ для ядра, он сокращается до 3 ГБ. SEGMEXEC предоставляет разделение посередине этого адресного пространства 3 ГБ, ограничивая рандомизацию до 1,5 ГБ. Страницы имеют размер 4 КиБ, а рандомизации выравниваются по страницам. Четыре верхних MSB отбрасываются при рандомизации, так что куча существует в начале, а стек - в конце программы. Это сводится к тому, что стек и куча существуют в одной из нескольких миллионов позиций (23- и 24-битная рандомизация), а все библиотеки существуют в любой из примерно 65000 позиций.

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

Рандомизированная база стека [ править ]

PaX произвольно смещает основание стека с шагом в 16 байтов, комбинируя случайное размещение фактического сегмента виртуальной памяти с промежутком в стеке подстраницы. Общая величина рандомизации зависит от размера виртуальной памяти; например, база стека находится где-то в диапазоне 256 МБ на 32-битных архитектурах, что дает 16 миллионов возможных позиций или 24 бита энтропии.

Рис. 3 Атака разбивания стека. Цель атаки сохраняет тот же адрес; но полезная нагрузка перемещается вместе со стеком.

Рандомизация базы стека влияет на доставку полезной нагрузки во время атак шеллкода и возврата в libc . Подобные атаки изменяют поле указателя возврата на адрес полезной нагрузки. При условии, что адрес стека не просочился и, следовательно, неизвестен противнику, вероятность успеха значительно снижается; положение стека непредсказуемо, и отсутствие полезной нагрузки может привести к сбою программы.

В случае шелл- кода к полезной нагрузке может быть добавлен ряд инструкций, называемых слайдом NOP или NOP sled. Это добавит еще один успешный случай на каждые 16 байтов слайда NOP. 16 байтов слайда NOP увеличивают вероятность успеха с 1 / 16M до 2 / 16M; 128 байт слайда NOP увеличивают это значение до 9 / 16M. Увеличение количества успешных попыток прямо пропорционально размеру слайда NOP; удвоение длины любого заданного слайда NOP удваивает шансы на успешную атаку.

Атаки с возвратом в libc не используют код, а скорее внедряют фреймы стека фиксированной ширины. Из-за этого кадры стека должны повторяться с точным выравниванием по 16 байтам. Часто кадр стека будет больше, чем это, что дает повторяющиеся полезные нагрузки кадра стека той же длины, что и заданная цепочка NOP, меньше влияет на вероятность успеха атак.

Рандомизированная база mmap () [ править ]

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

Любой вызов mmap () может указывать или не указывать смещение в виртуальной памяти для выделения сопоставления. Если смещение не указано, его выбор зависит от операционной системы. Linux делает это, вычисляя смещение предсказуемым образом, начиная с предопределенного виртуального адреса, называемого базой mmap () . Из-за этого при каждом запуске процесса исходные библиотеки, такие как стандартная библиотека C или libc, загружаются в одно и то же место.

Когда включена случайная база mmap (), PaX случайным образом сдвигает базу mmap (), влияя на расположение всех библиотек и другие неспецифические вызовы mmap (). Это приводит к тому, что весь динамически связанный код, то есть общие объекты, каждый раз отображается с различным, случайно выбранным смещением. Злоумышленники, которым требуется функция в определенной библиотеке, должны угадать, где эта библиотека загружена в пространство виртуальной памяти, чтобы вызвать ее. Это затрудняет атаки с возвратом к libc; хотя инъекции шелл-кода могут по-прежнему искать адрес любой функции в глобальной таблице смещений .

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

Когда исполняемые файлы ET_DYN, то есть исполняемые файлы, скомпилированные с позиционно-независимым кодом таким же образом, как и разделяемые библиотеки, загружаются, их база также выбирается случайным образом, так как они помещаются в ОЗУ с помощью mmap (), как обычные общие объекты.

При объединении неисполняемого стека с базовым рандомизацией mmap () сложность использования ошибок, защищенных PaX, значительно возрастает из-за принудительного использования атак с возвратом к libc. В 32-битных системах это составляет 16 порядков ; то есть шансы на успех рекурсивно уменьшаются вдвое в 16 раз. В сочетании с рандомизацией стека эффект может быть поразительным; если каждый человек в мире (при условии, что всего 6 миллиардов) атакует систему один раз, примерно от 1 до 2 должны добиться успеха в 32-битной системе. 64-битные системы, конечно, выигрывают от большей рандомизации.

Рандомизированная база ET_EXEC [ править ]

PaX может случайным образом отображать не независимый от позиции код в RAM; однако это создает несколько проблем. Во-первых, это требует дополнительных затрат на производительность. Во-вторых, в редких случаях он вызывает ложные срабатывания, в результате чего PaX без причины прекращает процесс . Настоятельно рекомендуется компилировать исполняемые файлы ET_DYN, чтобы они были на 100% независимым от позиции кодом.

На рандомизацию исполняемой базы загрузки для исполняемых файлов ET_EXEC с фиксированной позицией повлияла уязвимость безопасности в коде зеркалирования виртуальных машин в PaX. Для тех, кто не обновлялся, недостаток можно было обойти, отключив битовую эмуляцию SEGMEXEC NX и рандомизацию исполняемой базы RANDEXEC.

Бинарная маркировка [ править ]

PaX позволяет помечать исполняемые файлы в формате Executable и Linkable с уменьшенными ограничениями с помощью инструментов chpax и paxctl . Эти отметки существуют в заголовке ELF и, следовательно, не зависят от файловой системы и являются частью самого файлового объекта. Это означает, что маркировка сохраняется за счет упаковки, копирования, архивирования, шифрования и перемещения объектов. Инструмент chpax устарел в пользу paxctl.

PaX допускает индивидуальную маркировку как для PAGEEXEC, так и для SEGMEXEC; рандомизация mmap (), стека и базы кучи; рандомизация исполняемой базы для двоичных файлов ET_EXEC; ограничение mprotect (); и имитация батутов.

В случае chpax некоторые инструменты, такие как полоса, могут потерять маркировку; использование paxctl для установки PT_PAX_FLAGS - единственный надежный метод. Инструмент paxctl использует новый заголовок программы ELF, специально созданный для флагов PaX. Эти отметки могут быть явно включены, выключены или отключены. Если этот параметр не задан, решение о том, какие настройки использовать, принимает код PaX в ядре и зависит от общесистемных настроек программного режима PaX.

История [ править ]

Это неполная история PaX, которая будет обновляться по мере поступления дополнительной информации.

  • Октябрь 2000 г .: Впервые выпущен PaX с базовым методом PAGEEXEC.
  • Ноябрь 2000: выпущена первая версия MPROTECT.
  • Июнь 2001: ASLR (рандомизация mmap) реализована, но не выпущена
  • Июль 2001 г .: выпущен ASLR.
  • Август 2001: выпущен ASLR с дополнительным стеком и рандомизацией PIE.
  • Июль 2002: Выпущены VMA Mirroring и RANDEXEC.
  • Октябрь 2002: выпущен SEGMEXEC.
  • Октябрь 2002: выпущен ASLR с дополнительной рандомизацией стека ядра.
  • Февраль 2003: Представлен метод маркировки EI_PAX ELF.
  • Апрель 2003 г .: выпущен KERNEXEC (неисполняемые страницы ядра).
  • Июль 2003: выпущен ASLR с дополнительной рандомизацией brk.
  • Февраль 2004: Представлен метод маркировки PT_PAX_FLAGS ELF.
  • Май 2004 г .: PAGEEXEC дополнен функцией отслеживания лимитов сегмента кода для повышения производительности.
  • 4 марта 2005 г .: Объявление об уязвимости зеркалирования VMA, выпущены новые версии PaX и grsecurity, все предыдущие версии, использующие SEGMEXEC и RANDEXEC, имеют уязвимость повышения привилегий.
  • 1 апреля 2005 г .: Из-за этой уязвимости проект PaX должен был быть передан новому разработчику, но, поскольку кандидат не появился, старый разработчик с тех пор продолжает обслуживание.

См. Также [ править ]

  • Exec Shield
  • Укрепление (вычисление)
  • Система обнаружения вторжений
  • Система предотвращения вторжений
  • Linux с повышенной безопасностью
  • RSBAC

Ссылки [ править ]

  1. ^ «USNAnalysis - Ubuntu Wiki» . Проверено 2 июня +2016 .[ самостоятельно опубликованный источник ]
  2. ^ "pax.txt" . Проверено 2 июня +2016 .
  3. ^ "aslr.txt" . Проверено 2 июня +2016 .

Дальнейшее чтение [ править ]

  • Документация PaX

Внешние ссылки [ править ]

  • Домашняя страница PaX
  • Будущее PaX 2003
  • Презентация PaX 14.10.2003
  • Батуты для вложенных функций
  • Использование методов смягчения последствий 2004 г.
  • Анализ USN Ubuntu Linux
  • Ошибка безопасности повышения привилегий PaX 9 марта 2005 г.
  • Код подтверждения концепции повышения привилегий PaX 2005