WikiDer > Защита от переполнения буфера

Buffer overflow protection

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

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

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

Существует несколько реализаций защиты от переполнения буфера, в том числе для Коллекция компиляторов GNU, LLVM, Microsoft Visual Studio, и другие компиляторы.

Обзор

Основная статья: Переполнение буфера стека

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

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

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

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

Канарейки

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

Терминология - это ссылка на историческую практику использования канарейки в угольных шахтах, поскольку они будут затронуты токсичными газами раньше, чем шахтеры, что обеспечит биологическую систему предупреждения. Канарейки также известны как печенье, который предназначен для создания образа «сломанного файла cookie», когда значение повреждено.

Используются три типа канареек: терминатор, случайный, и случайный XOR. Текущие версии StackGuard поддерживают все три, а ProPolice поддерживает терминатор и случайный канарейки.

Терминатор канарейки

Терминатор канарейки используйте наблюдение, что большинство атак на переполнение буфера основаны на определенных строковых операциях, которые заканчиваются признаками конца строки. Реакция на это наблюдение состоит в том, что канарейки построены из ноль терминаторы, CR, LF и -1. В результате злоумышленник должен написать нулевой символ перед записью адреса возврата, чтобы не изменить канарейку. Это предотвращает атаки с использованием strcpy () и другие методы, которые возвращаются при копировании нулевого символа, в то время как нежелательный результат - известность канарейки. Даже при наличии защиты злоумышленник потенциально может перезаписать канарейку с ее известным значением и контрольную информацию с несовпадающими значениями, передав таким образом код проверки канарейки, который выполняется незадолго до команды возврата из вызова конкретного процессора.

Случайные канарейки

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

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

Случайные канарейки XOR

Случайные канарейки XOR - это случайные канарейки, которые скремблируются с использованием XOR с использованием всех или части управляющих данных. Таким образом, после того, как канарейка или контрольные данные будут затерты, значение канарейки будет неправильным.

Случайные канарейки XOR имеют те же уязвимости, что и случайные канарейки, за исключением того, что метод «чтения из стека» получения канарейки немного сложнее. Злоумышленник должен получить канарейку, алгоритм и управляющие данные, чтобы повторно сгенерировать исходную канарейку, необходимую для подделки защиты.

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

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

Проверка границ

Основная статья: Проверка границ

Проверка границ - это метод на основе компилятора, который добавляет информацию о границах времени выполнения для каждого выделенного блока памяти и проверяет все указатели на соответствие указателям во время выполнения. Для C и C ++ проверка границ может выполняться во время вычисления указателя.[4] или во время разыменования.[5][6][7]

Реализации этого подхода используют либо центральный репозиторий, который описывает каждый выделенный блок памяти, либо[4][5][6] или же жирные указатели,[7] которые содержат как указатель, так и дополнительные данные, описывающие область, на которую они указывают.

Теги

Теги[8] основан на компиляторе или на оборудовании (требуется помеченная архитектура) метод пометки типа фрагмента данных в памяти, используемый в основном для проверки типов. Помечая определенные области памяти как неисполняемые, он эффективно предотвращает хранение исполняемого кода в памяти, выделенной для хранения данных. Кроме того, определенные области памяти могут быть отмечены как невыделенные, что предотвращает переполнение буфера.

Исторически тегирование использовалось для реализации языков программирования высокого уровня;[9] при соответствующей поддержке со стороны Операционная система, тегирование также может использоваться для обнаружения переполнения буфера.[10] Примером может служить Бит NX аппаратная функция, поддерживаемая Intel, AMD и РУКА процессоры.

Реализации

Коллекция компиляторов GNU (GCC)

Защита от разрушения стека была впервые реализована StackGuard в 1997 г., опубликовано в 1998 г. Симпозиум по безопасности USENIX.[11] StackGuard был представлен как набор исправлений для серверной части Intel x86 GCC 2.7. StackGuard поддерживался для Иммуникс Дистрибутив Linux с 1998 по 2003 год был расширен реализациями терминатора, случайных и случайных канареек XOR. StackGuard был предложен для включения в GCC 3.x на конференции GCC 2003 Summit Proceedings,[12] но этого так и не удалось достичь.

С 2001 по 2005 гг. IBM разработали патчи GCC для защиты от разрушения стека, известные как ProPolice.[13] Он улучшил идею StackGuard, разместив буферы после локальных указателей и аргументов функций в кадре стека. Это помогло избежать повреждения указателей, предотвращая доступ к произвольным участкам памяти.

Красная шляпа Однако инженеры выявили проблемы с ProPolice и в 2005 году повторно реализовали защиту от разбиения стека для включения в GCC 4.1.[14][15] Эта работа представила -fstack-протектор флаг, который защищает только некоторые уязвимые функции, и -fstack-протектор-все флаг, который защищает все функции независимо от того, нужны они им или нет.[16]

В 2012, Google инженеры реализовали -fstack-протектор-сильный флаг для достижения лучшего баланса между безопасностью и производительностью.[17] Этот флаг защищает больше видов уязвимых функций, чем -fstack-протектор делает, но не все функции, обеспечивая лучшую производительность, чем -fstack-протектор-все. Он доступен в GCC, начиная с его версии 4.9.[18]

Все Fedora пакеты скомпилированы с -fstack-протектор начиная с Fedora Core 5 и -fstack-протектор-сильный начиная с Fedora 20.[19][20] Большинство пакетов в Ubuntu составлены с -fstack-протектор с 6.10.[21] Каждый Arch Linux пакет скомпилирован с -fstack-протектор с 2011 года.[22] Все пакеты Arch Linux, созданные с 4 мая 2014 г., используют -fstack-протектор-сильный.[23] Защита стека используется только для некоторых пакетов в Debian,[24] и только для FreeBSD базовая система с 8.0.[25] Защита стека является стандартной в некоторых операционных системах, включая OpenBSD,[26] Закаленный Gentoo[27] и DragonFly BSD[нужна цитата].

StackGuard и ProPolice не могут защитить от переполнения в автоматически выделенных структурах, которые переходят в указатели функций. ProPolice, по крайней мере, изменит порядок размещения, чтобы выделить такие структуры перед указателями на функции. Отдельный механизм для защита указателя был предложен в PointGuard[28] и доступен в Microsoft Windows.[29]

Microsoft Visual Studio

Набор компиляторов от Microsoft реализует защиту от переполнения буфера с версии 2003 через / GS переключатель командной строки, который включен по умолчанию с версии 2005.[30] С помощью / GS- отключает защиту.

Компилятор IBM

Защита от разрушения стека может быть включена флагом компилятора -qstackprotect.[31]

Clang /LLVM

Clang поддерживает три детектора переполнения буфера, а именно:AddressSanitizer (-fsanitize = адрес),[6]-fsanitize = границы,[32]и SafeCode.[33]Эти системы имеют разные компромиссы с точки зрения снижения производительности, накладных расходов на память и классов обнаруженных ошибок. Защита стека является стандартной в некоторых операционных системах, включая OpenBSD.[34]

Компилятор Intel

Компилятор Intel C и C ++ поддерживает защиту от разрушения стека с опциями, аналогичными тем, которые предоставляются GCC и Microsoft Visual Studio.[35]

Отказоустойчивый C

Отказоустойчивый C[7] - это компилятор ANSI C с открытым исходным кодом, безопасный для памяти, который выполняет проверку границ на основе жирных указателей и объектно-ориентированного доступа к памяти.[36]

StackGhost (аппаратный)

Изобретенный Майк Францен, StackGhost - это простая настройка процедуры заполнения / заполнения окна регистров, которая значительно затрудняет использование переполнения буфера. Он использует уникальную аппаратную функцию Sun Microsystems SPARC архитектура (то есть: отложенное заполнение / заполнение окна регистров в стеке) для обнаружения изменений возврата указатели (распространенный способ эксплуатировать для перехвата путей выполнения) прозрачно, автоматически защищая все приложения, не требуя изменений двоичного кода или исходного кода. Влияние на производительность незначительно, менее одного процента. Результирующий GDB проблемы были решены Марк Кеттенис два года спустя, что позволило включить эту функцию. После этого события код StackGhost был интегрирован (и оптимизирован) в OpenBSD/ SPARC.

Пример с канарейкой

Нормальное распределение буфера для x86 архитектуры и другие подобные архитектуры показаны в переполнение буфера Вход. Здесь мы покажем измененный процесс в отношении StackGuard.

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

(CTLI) (RETA)

В C, функция может содержать множество различных структур данных для каждого вызова. Каждый фрагмент данных, созданный по запросу, помещается в кадр стека по порядку и, таким образом, упорядочивается от конца до начала памяти. Ниже представлена ​​гипотетическая функция и ее стековый фрейм.

int фу() {  int а;             / * целое число * /  int *б;            / * указатель на целое число * /  char c[10];        / * символьные массивы * /  char d[3];  б = &а;            / * инициализируем b, чтобы указать местоположение a * /  strcpy(c,get_c()); / * получаем откуда-то c, записываем в c * /  *б = 5;            / * данные в точке памяти, указываемой b, установлены на 5 * /  strcpy(d,get_d());  возвращаться *б;         / * читать из b и передавать его вызывающему * /}
(d ..) (c .........) (b ...) (a ...) (CTLI) (RETA)

В этой гипотетической ситуации, если в массив записано более десяти байтов c, или более 13 в массив символов d, избыток перейдет в целочисленный указатель б, затем в целое число а, затем в управляющую информацию и, наконец, в обратный адрес. Путем перезаписи б, указатель ссылается на любую позицию в памяти, вызывая чтение с произвольного адреса. Путем перезаписи RETA, функция может быть выполнена для выполнения другого кода (при попытке возврата) либо существующих функций (ret2libc) или код, записанный в стек при переполнении.

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

Защита от переполнения буфера реализована как изменение компилятора. Таким образом, защита может изменять структуру данных в кадре стека. Это точно так в таких системах, как ProPolice. Автоматические переменные вышеупомянутой функции переупорядочиваются более безопасно: массивы c и d выделяются первыми в стековом фрейме, который помещает целое число а и целочисленный указатель б перед ними в памяти. Таким образом, кадр стека становится

(b ...) (a ...) (d ..) (c .........) (CTLI) (RETA)

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

(b ...) (a ...) (d ..) (c .........) (CNRY) (CTLI) (RETA)

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

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

Положение канарейки зависит от реализации, но всегда между буферами и защищенными данными. Различное положение и длина имеют разные преимущества.

Смотрите также

Рекомендации

  1. ^ Фитен, Уильям Л .; Сикорд, Роберт (27 марта 2007 г.). «ВТ-МБ. Нарушение границ памяти». США CERT.
  2. ^ Леви, Элиас (1996-11-08). «Разбить стопку ради удовольствия и прибыли». Phrack. 7 (49): 14.
  3. ^ «Переполнение буфера: атаки и защита от уязвимости десятилетия *» (PDF). Архивировано из оригинал (PDF) на 2013-03-09.
  4. ^ а б «Проверка границ для C». Doc.ic.ac.uk. Архивировано из оригинал на 2016-03-26. Получено 2014-04-27.
  5. ^ а б «SAFECode: безопасная виртуальная архитектура». Sva.cs.illinois.edu. 2009-08-12. Получено 2014-04-27.
  6. ^ а б c "Google / дезинфицирующие средства".
  7. ^ а б c «Отказоустойчивый C: главная страница». Staff.aist.go.jp. 2013-05-07. Архивировано из оригинал на 2016-07-07. Получено 2014-04-27.
  8. ^ «Вторник, 5 апреля 2005 г.» (PDF). Feustel.us. Архивировано из оригинал (PDF) 23 июня 2016 г.. Получено 2016-09-17.
  9. ^ «Теги и проверка типов в LISP: аппаратные и программные подходы». ACM.
  10. ^ «Обзор безопасности MCP серверов ClearPath Enterprise Servers» (PDF). Public.support.unisys.com. Архивировано из оригинал (PDF) на 2013-01-24. Получено 2014-04-27.
  11. ^ "Доклады - 7-й симпозиум по безопасности USENIX, 1998 г.". Usenix.org. 2002-04-12. Получено 2014-04-27.
  12. ^ «Материалы саммита разработчиков GCC» (PDF). Май 2003. Архивировано 15 июля 2004 г.. Получено 2016-09-17.CS1 maint: BOT: статус исходного URL-адреса неизвестен (связь)
  13. ^ «Расширение GCC для защиты приложений от атак, разбивающих стек». Research.ibm.com. Получено 2014-04-27.
  14. ^ «Серия выпусков GCC 4.1 - Изменения, новые функции и исправления - Проект GNU - Фонд свободного программного обеспечения (FSF)». Gcc.gnu.org. Получено 2014-04-27.
  15. ^ "Ричард Хендерсон - [rfc] повторная реализация средства защиты от разбивания стеков IBM". Gcc.gnu.org. Получено 2014-04-27.
  16. ^ «Параметры оптимизации - Использование коллекции компиляторов GNU (GCC)». Gcc.gnu.org. Получено 2014-04-27.
  17. ^ «Хан Шэнь (ææ) - [ПАТЧ] Добавить новую опцию« -fstack-protector-strong »(патч / документ внутри)». Gcc.gnu.org. 2012-06-14. Получено 2014-04-27.
  18. ^ Эдж, Джейк (5 февраля 2014 г.). ""Сильная "защита стека для GCC". Еженедельные новости Linux. Получено 28 ноября 2014. Он попал в GCC 4.9.
  19. ^ «Функции безопасности». FedoraProject. 2013-12-11. Получено 2014-04-27.
  20. ^ "# 1128 (переключение с" -fstack-protector "на" -fstack-protector-strong "в Fedora 20) - FESCo". Fedorahosted.org. Получено 2014-04-27.
  21. ^ «Безопасность / Возможности - Ubuntu Wiki». Wiki.ubuntu.com. Получено 2014-04-27.
  22. ^ «FS # 18864: рассмотрите возможность включения защиты GCC от разрушения стека (ProPolice, SSP) для всех пакетов». Bugs.archlinux.org. Получено 2014-04-27.
  23. ^ "svntogit / packages.git - Git клон репозитория пакетов".
  24. ^ «Статистика повышения безопасности Debian». Outflux.net. Получено 2014-04-27.
  25. ^ "Примечания к выпуску FreeBSD 8.0-RELEASE". Freebsd.org. 2013-11-13. Получено 2014-04-27.
  26. ^ "Страница руководства OpenBSD gcc-local (1)". gcc поставляется с ProPolice расширение защиты стека, которое по умолчанию включено.
  27. ^ "Hardened / Toolchain - Gentoo Wiki". 2016-07-31. GCC с усиленной защитой Gentoo включает протектор стека по умолчанию, если явно не запрошено не делать этого.
  28. ^ «12-й симпозиум по безопасности USENIX - Технический доклад».
  29. ^ «Блоги MSDN - получайте самую свежую информацию, идеи, объявления и новости от экспертов и разработчиков Microsoft в блогах MSDN».
  30. ^ "/ GS (Проверка безопасности буфера) (C ++)". msdn.microsoft.com. Получено 2014-04-27.
  31. ^ "qstackprotect". Publib.boulder.ibm.com. Получено 2014-04-27.
  32. ^ "Руководство пользователя компилятора Clang - документация Clang 3.5". Clang.llvm.org. Получено 2014-04-27.
  33. ^ "SAFECode". Safecode.cs.illinois.edu. Получено 2014-04-27.
  34. ^ "Страница руководства OpenBSD clang-local (1)". clang поставляется с включенной по умолчанию защитой стека, что эквивалентно -fstack-протектор-сильный вариант на других системах.
  35. ^ «Справочное руководство для Intel C ++ Compiler 15.0: fstack-security-check, GS». software.intel.com. Получено 2015-02-13.
  36. ^ "thesis.dvi" (PDF). Staff.aist.go.jp. Получено 2016-09-17.

внешняя ссылка