stringtranslate.com

Переполнение буфера

Визуализация программного переполнения буфера. Данные записываются в A, но они слишком велики, чтобы поместиться в A, поэтому они переполняются в B.

В программировании и информационной безопасности переполнение буфера или переполнение буфера — это аномалия , при которой программа записывает данные в буфер за пределами выделенной памяти буфера , перезаписывая соседние ячейки памяти .

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

Использование поведения переполнения буфера является хорошо известным эксплойтом безопасности . Во многих системах структура памяти программы или системы в целом четко определена. Отправляя данные, вызывающие переполнение буфера, можно выполнить запись в области, которые, как известно, содержат исполняемый код , и заменить его вредоносным кодом или выборочно перезаписать данные, относящиеся к состоянию программы, что приведет к поведению, не предусмотренному пользователем. оригинальный программатор. Буферы широко распространены в коде операционной системы (ОС), поэтому можно проводить атаки, повышающие привилегии и получающие неограниченный доступ к ресурсам компьютера. Знаменитый червь Морриса в 1988 году использовал это как один из методов атаки.

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

Техническое описание

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

Пример

В следующем примере, выраженном на языке C , программа имеет две переменные, расположенные рядом в памяти: строковый буфер длиной 8 байт, A, и двухбайтовое целое число с прямым порядком байтов , B.

символ A [ 8 ] = "" ; беззнаковый короткий B = 1979 ;

Первоначально A содержит только ноль байт, а B содержит число 1979.

Теперь программа пытается сохранить строку с нулевым символом в конце "excessive" в кодировке ASCII в буфере A.

strcpy ( A , «чрезмерный» );

"excessive"имеет длину 9 символов и кодирует 10 байт, включая нулевой терминатор, но A может занимать только 8 байт. Не проверив длину строки, она также перезаписывает значение B:

Значение B теперь случайно заменено числом, сформированным из части строки символов. В этом примере «e», за которым следует нулевой байт, будет равно 25856.

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

Чтобы предотвратить переполнение буфера в этом примере, вызов strcpyможно заменить на strlcpy, который принимает максимальную емкость A (включая символ нулевого завершения) в качестве дополнительного параметра и гарантирует, что будет записано не более этого объема данных. к А:

strlcpy ( A , "чрезмерный" , sizeof ( A ));

Если она доступна, strlcpyбиблиотечная функция предпочтительнее, чем strncpyта, которая не завершает буфер назначения нулем, если длина исходной строки больше или равна размеру буфера (третий аргумент, передаваемый функции). Поэтому Aне может заканчиваться нулем и не может рассматриваться как допустимая строка в стиле C.

Эксплуатация

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

Эксплойт на основе стека

Существует несколько способов манипулирования программой, используя переполнение буфера стека:

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

Эксплуатация на основе кучи

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

Уязвимость Microsoft GDI + при обработке файлов JPEG является примером опасности, которую может представлять переполнение кучи. [5]

Барьеры для эксплуатации

Манипулирование буфером, происходящее до его чтения или выполнения, может привести к провалу попытки эксплуатации. Эти манипуляции могут снизить угрозу эксплуатации, но не могут сделать ее невозможной. Манипуляции могут включать преобразование в верхний или нижний регистр, удаление метасимволов и фильтрацию небуквенно- цифровых строк. Однако существуют методы обхода этих фильтров и манипуляций, такие как буквенно-цифровой шеллкод , полиморфный код , самомодифицирующийся код и атаки с возвратом в libc . Те же методы можно использовать, чтобы избежать обнаружения системами обнаружения вторжений . В некоторых случаях, в том числе при преобразовании кода в Unicode , [6] угроза уязвимости была неверно истолкована разоблачителями как всего лишь отказ в обслуживании, тогда как на самом деле удаленное выполнение произвольного кода возможно.

Практичность эксплуатации

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

Техника салазок NOP

Иллюстрация полезной нагрузки NOP-салазок в стеке.

NOP-салазки — старейший и наиболее широко известный метод использования переполнения буфера стека. [7] Он решает проблему поиска точного адреса буфера за счет эффективного увеличения размера целевой области. Для этого гораздо большие разделы стека повреждаются с помощью недействующей машинной инструкции. В конце предоставленных злоумышленником данных, после пустых инструкций, злоумышленник помещает инструкцию для выполнения относительного перехода к началу буфера, где расположен шелл-код . Этот набор пустых операций называется «NOP-салазками», потому что, если адрес возврата перезаписывается каким-либо адресом в неактивной области буфера, выполнение будет «скользить» вниз по пустым операциям до тех пор, пока не будет перенаправляется на реальный вредоносный код переходом в конце. Этот метод требует, чтобы злоумышленник угадал, где в стеке находится NOP-след, а не сравнительно небольшой шеллкод. [8]

Из-за популярности этого метода многие поставщики систем предотвращения вторжений будут искать этот шаблон бездействующих машинных инструкций в попытке обнаружить используемый шеллкод. Важно отметить, что NOP-салазки не обязательно содержат только традиционные безоперационные машинные инструкции. Любая инструкция, которая не нарушает состояние машины до такой степени, что шеллкод не запускается, может использоваться вместо аппаратного бездействия. В результате для авторов эксплойтов стало обычной практикой составлять неактивный слейд из случайно выбранных инструкций, которые не оказывают реального влияния на выполнение шеллкода. [9]

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

Переход к адресу, хранящемуся в регистровой технике

Метод «перехода к регистрации» позволяет надежно использовать переполнение буфера стека без необходимости дополнительного места для NOP-салазок и без необходимости угадывать смещения стека. Стратегия состоит в том, чтобы перезаписать указатель возврата чем-то, что заставит программу перейти к известному указателю, хранящемуся в регистре, который указывает на управляемый буфер и, следовательно, на шелл-код. Например, если регистр A содержит указатель на начало буфера, то любой переход или вызов, использующий этот регистр в качестве операнда, может использоваться для получения контроля над потоком выполнения. [11]

Инструкция из ntdll.dll для вызова DbgPrint()процедуры содержит машинный код операции i386 для jmp esp.

На практике программа не может намеренно содержать инструкции для перехода к определенному регистру. Традиционное решение состоит в том, чтобы найти непреднамеренный экземпляр подходящего кода операции в фиксированном месте где-то в памяти программы. На рисунке E слева показан пример такого непреднамеренного выполнения инструкции i386 jmp esp. Код операции для этой инструкции — FF E4. [12] Эту двухбайтовую последовательность можно найти по смещению в один байт от начала инструкции call DbgPrintпо адресу 0x7C941EED. Если злоумышленник перезапишет адрес возврата программы этим адресом, программа сначала перейдет к 0x7C941EED, интерпретирует код операции FF E4как jmp espинструкцию, а затем перейдет на вершину стека и выполнит код злоумышленника. [13]

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

Этот метод также позволяет размещать шеллкод после перезаписанного обратного адреса на платформе Windows. Поскольку исполняемые файлы в основном основаны на адресе, 0x00400000а x86 представляет собой архитектуру Little Endian , последний байт обратного адреса должен быть нулевым, что завершает копирование буфера, и за его пределами ничего не записывается. Это ограничивает размер шеллкода размером буфера, что может быть слишком ограничительным. Библиотеки DLL расположены в верхней части памяти (выше 0x01000000) и поэтому имеют адреса, не содержащие нулевых байтов, поэтому этот метод может удалить нулевые байты (или другие запрещенные символы) из перезаписанного адреса возврата. Используемый таким образом метод часто называют «прыжком на батуте DLL».

Защитные контрмеры

Для обнаружения или предотвращения переполнения буфера использовались различные методы с различными компромиссами. В следующих разделах описаны доступные варианты и реализации.

Выбор языка программирования

Ассемблер, C и C++ — популярные языки программирования, уязвимые к переполнению буфера, отчасти потому, что они допускают прямой доступ к памяти и не являются строго типизированными . [15] C не обеспечивает встроенной защиты от доступа или перезаписи данных в любой части памяти. Точнее, он не проверяет, находятся ли данные, записанные в буфер, в пределах границ этого буфера. Стандартные библиотеки C++ предоставляют множество способов безопасной буферизации данных, а стандартная библиотека шаблонов C++ (STL) предоставляет контейнеры, которые могут дополнительно выполнять проверку границ, если программист явно вызывает проверки при доступе к данным. Например, vectorфункция-член at()выполняет проверку границ и выдает out_of_range исключение , если проверка границ не удалась. [16] Однако C++ ведет себя так же, как C, если проверка границ не вызывается явно. Методы предотвращения переполнения буфера также существуют для C.

Языки, которые строго типизированы и не допускают прямого доступа к памяти, такие как COBOL, Java, Python и другие, в большинстве случаев предотвращают переполнение буфера. [15] Многие языки программирования, кроме C или C++, обеспечивают проверку во время выполнения, а в некоторых случаях даже проверку во время компиляции, которая может отправить предупреждение или вызвать исключение, в то время как C или C++ перезаписывают данные и продолжают выполнять инструкции до тех пор, пока не будут получены ошибочные результаты. , что может привести к сбою программы. Примеры таких языков включают Ada , Eiffel , Lisp , Modula -2 , Smalltalk , OCaml и такие C-производные, как Cyclone , Rust и D. Среды байт-кода Java и .NET Framework также требуют проверки границ всех массивов. Почти каждый интерпретируемый язык имеет защиту от переполнения буфера, сигнализируя о четко определенной ошибке. Языки, которые предоставляют достаточно информации о типах для проверки границ, часто предоставляют возможность включить или отключить ее. Статический анализ кода может устранить многие динамические проверки привязок и типов, но плохая реализация и неловкие случаи могут значительно снизить производительность. Разработчики программного обеспечения должны тщательно учитывать соотношение между безопасностью и производительностью при принятии решения о том, какой язык и настройки компилятора использовать.

Использование безопасных библиотек

Проблема переполнения буфера распространена в языках C и C++, поскольку они предоставляют низкоуровневые детали представления буферов как контейнеров для типов данных. Переполнения буфера можно избежать, поддерживая высокую степень корректности кода, выполняющего управление буфером. Также давно рекомендуется избегать стандартных библиотечных функций, границы которых не проверяются, таких как gets, scanfи strcpy. Червь Морриса воспользовался getsвызовом Fingerd . [17]

Хорошо написанные и протестированные библиотеки абстрактных типов данных, которые централизуют и автоматически выполняют управление буфером, включая проверку границ, могут уменьшить возникновение и влияние переполнения буфера. Основными типами данных в языках, в которых часто встречаются переполнения буфера, являются строки и массивы. Таким образом, библиотеки, предотвращающие переполнение буфера в этих типах данных, могут обеспечить подавляющее большинство необходимого покрытия. Однако неправильное использование этих безопасных библиотек может привести к переполнению буфера и другим уязвимостям, и, естественно, любая ошибка в библиотеке также является потенциальной уязвимостью. «Безопасные» реализации библиотек включают «The Better String Library», [18] Vstr [19] и Erwin. [20] Библиотека C операционной системы OpenBSD предоставляет функции strlcpy и strlcat , но они более ограничены, чем реализации полностью безопасных библиотек.

В сентябре 2007 года был опубликован Технический отчет 24731, подготовленный комитетом по стандартам C. [21] Он определяет набор функций, основанных на строках стандартной библиотеки C и функциях ввода-вывода, с дополнительными параметрами размера буфера. Однако эффективность этих функций для уменьшения переполнения буфера является спорной. Они требуют вмешательства программиста для каждого вызова функции, что эквивалентно вмешательству, которое могло бы сделать безопасным переполнение буфера функций аналогичной старой стандартной библиотеки. [22]

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

Защита от переполнения буфера используется для обнаружения наиболее распространенных случаев переполнения буфера путем проверки того, что стек не был изменен при возврате функции. Если он был изменен, программа завершает работу с ошибкой сегментации . Три таких системы — это Libsafe [23] и патчи gcc StackGuard [24] и ProPolice [25] .

Реализация Microsoft режима предотвращения выполнения данных (DEP) явно защищает указатель на обработчик структурированных исключений (SEH) от перезаписи. [26]

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

Защита указателя

Переполнение буфера происходит путем манипулирования указателями , включая сохраненные адреса. PointGuard был предложен как расширение компилятора, позволяющее злоумышленникам надежно манипулировать указателями и адресами. [27] Этот подход работает, когда компилятор добавляет код для автоматического XOR-кодирования указателей до и после их использования. Теоретически, поскольку злоумышленник не знает, какое значение будет использоваться для кодирования и декодирования указателя, невозможно предсказать, на что будет указывать указатель, если он будет перезаписан новым значением. PointGuard так и не был выпущен, но Microsoft реализовала аналогичный подход, начиная с Windows XP SP2 и Windows Server 2003 SP1. [28] Вместо того, чтобы реализовать защиту указателей как автоматическую функцию, Microsoft добавила подпрограмму API, которую можно вызывать. Это позволяет повысить производительность (поскольку он не используется постоянно), но накладывает на программиста обязанность знать, когда его использование необходимо.

Поскольку XOR является линейным, злоумышленник может манипулировать закодированным указателем, перезаписывая только младшие байты адреса. Это может обеспечить успех атаки, если злоумышленник сможет несколько раз попытаться использовать эксплойт или завершить атаку, заставив указатель указывать на одно из нескольких мест (например, любое место в салазке NOP). [29] Microsoft добавила случайную ротацию в свою схему кодирования, чтобы устранить эту слабость, связанную с частичной перезаписью. [30]

Исполняемая космическая защита

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

Некоторые процессоры поддерживают функцию, называемую битом NX («No eXecute») или XD («eXecute Disabled»), которая в сочетании с программным обеспечением может использоваться для пометки страниц данных (например, тех, которые содержат стек и кучу) как читаемых. и доступен для записи, но не исполняемый.

Некоторые операционные системы Unix (например, OpenBSD , macOS ) поставляются с защитой исполняемого пространства (например, W^X ). Некоторые дополнительные пакеты включают в себя:

Более новые варианты Microsoft Windows также поддерживают защиту исполняемого пространства, называемую «Предотвращение выполнения данных» . [34] Собственные надстройки включают в себя:

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

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

Рандомизация макета адресного пространства (ASLR) — это функция компьютерной безопасности, которая включает в себя случайное расположение позиций ключевых областей данных, обычно включая базу исполняемого файла и положение библиотек, кучи и стека, в адресном пространстве процесса.

Рандомизация адресов виртуальной памяти , по которым можно найти функции и переменные, может затруднить, но не сделать невозможным использование переполнения буфера. Это также заставляет злоумышленника адаптировать попытку эксплуатации к конкретной системе, что препятствует попыткам интернет-червей . [37] Аналогичный, но менее эффективный метод — перебазировать процессы и библиотеки в виртуальное адресное пространство.

Глубокая проверка пакетов

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

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

Тестирование

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

История

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

Самая ранняя задокументированная враждебная эксплуатация переполнения буфера произошла в 1988 году. Это был один из нескольких эксплойтов, использованных червем Морриса для распространения через Интернет. Использованная программа представляла собой сервис Unix под названием «finger» . [41] Позже, в 1995 году, Томас Лопатич независимо заново обнаружил переполнение буфера и опубликовал свои выводы в списке рассылки по безопасности Bugtraq . [42] Год спустя, в 1996 году, Элиас Леви (также известный как Aleph One) опубликовал в журнале Phrack статью «Smashing the Stack for Fun and Profit», [43] пошаговое введение в использование стек-ориентированных систем. уязвимости переполнения буфера.

С тех пор как минимум два крупных интернет-червя использовали переполнение буфера для компрометации большого количества систем. В 2001 году червь Code Red воспользовался переполнением буфера в Microsoft Internet Information Services (IIS) 5.0 [44] , а в 2003 году червь SQL Slammer скомпрометировал машины под управлением Microsoft SQL Server 2000 . [45]

В 2003 году переполнение буфера, присутствующее в лицензионных играх для Xbox , было использовано, чтобы позволить нелицензионному программному обеспечению, включая доморощенные игры , запускаться на консоли без необходимости модификаций оборудования, известных как модчипы . [46] Эксплойт независимости PS2 также использовал переполнение буфера, чтобы добиться того же самого для PlayStation 2 . Хак «Сумерек» достиг того же самого с Wii , используя переполнение буфера в The Legend of Zelda: Twilight Princess .

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

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

  1. ^ Р. Шири (август 2007 г.). Глоссарий по интернет-безопасности, версия 2. Сетевая рабочая группа. дои : 10.17487/RFC4949 . РФК 4949. Информационный.
  2. ^ «CORE-2007-0219: Переполнение буфера удаленного ядра mbufs IPv6 OpenBSD» . Проверено 15 мая 2007 г.
  3. ^ «Современные цели переполнения» (PDF) . Архивировано (PDF) из оригинала 9 октября 2022 г. Проверено 5 июля 2013 г.
  4. ^ "База данных кодов операций Metasploit" . Архивировано из оригинала 12 мая 2007 года . Проверено 15 мая 2007 г.
  5. ^ «Бюллетень по безопасности Microsoft Technet MS04-028» . Майкрософт . Архивировано из оригинала 4 августа 2011 г. Проверено 15 мая 2007 г.
  6. ^ «Создание произвольного шелл-кода в расширенных строках Юникода» (PDF) . Архивировано из оригинала (PDF) 5 января 2006 г. Проверено 15 мая 2007 г.
  7. ^ Вангелис (08 декабря 2004 г.). «Эксплуатация переполнения стека: введение в классическую и расширенную технику переполнения». Wowhacker через Neworder. Архивировано из оригинала (текста) 18 августа 2007 года. {{cite journal}}: Требуется цитировать журнал |journal=( помощь )
  8. ^ Балабан, Мурат. «Раскрытие тайны о переполнении буфера» (текст) . Enderunix.org. {{cite journal}}: Требуется цитировать журнал |journal=( помощь )
  9. ^ Акритидис, П.; Евангелос П. Маркатос; М. Полихронакис; Костас Д. Анагностакис (2005). «STRIDE: обнаружение полиморфных салазок посредством анализа последовательности инструкций». (PDF) . Материалы 20-й Международной конференции по информационной безопасности IFIP (IFIP/SEC 2005) . Международная конференция ИФИП по информационной безопасности. Архивировано из оригинала (PDF) 1 сентября 2012 г. Проверено 4 марта 2012 г.
  10. ^ Кляйн, Кристиан (сентябрь 2004 г.). «Переполнение буфера» (PDF) . Архивировано из оригинала (PDF) 28 сентября 2007 г. {{cite journal}}: Требуется цитировать журнал |journal=( помощь )
  11. ^ Шах, Сомил (2006). «Написание плагинов Metasploit: от уязвимости к эксплойту» (PDF) . Взломать в коробке . Куала-Лумпур . Проверено 4 марта 2012 г.
  12. ^ Руководство разработчика программного обеспечения для архитектур Intel 64 и IA-32, том 2A: Справочник по набору инструкций, AM (PDF) . Корпорация Интел. Май 2007 г., стр. 3–508. Архивировано из оригинала (PDF) 29 ноября 2007 г.
  13. ^ Альварес, Серхио (5 сентября 2004 г.). «Реальный процесс Vuln-Dev Win32 Stack BufferOverFlow» (PDF) . Консультации по ИТ-безопасности . Проверено 4 марта 2012 г. {{cite journal}}: Требуется цитировать журнал |journal=( помощь )
  14. ^ Укай, Юджи; Соедер, Дерек; Перме, Райан (2004). «Зависимости от среды при эксплуатации Windows». Блэкхэт Япония . Япония: Цифровая безопасность eEye . Проверено 4 марта 2012 г.
  15. ^ ab https://www.owasp.org/index.php/Buffer_OverflowsBuffer Overflows. Статья об OWASP. Архивировано 29 августа 2016 г. на Wayback Machine.
  16. ^ "vector::at - Справочник по C++" . Cplusplus.com . Проверено 27 марта 2014 г.
  17. ^ «Архивная копия». Wiretap.area.com . Архивировано из оригинала 5 мая 2001 года . Проверено 6 июня 2022 г.{{cite web}}: CS1 maint: архивная копия в заголовке ( ссылка )
  18. ^ "Лучшая строковая библиотека" .
  19. ^ "Домашняя страница Vstr" . Архивировано из оригинала 5 марта 2017 г. Проверено 15 мая 2007 г.
  20. ^ "Домашняя страница Эрвина" . Проверено 15 мая 2007 г.
  21. ^ Международная организация по стандартизации (2007). «Информационные технологии. Языки программирования, их среды и интерфейсы системного программного обеспечения. Расширения библиотеки C. Часть 1. Интерфейсы проверки границ». Платформа онлайн-просмотра ISO .
  22. ^ «Инициатива по безопасному кодированию CERT» . Архивировано из оригинала 28 декабря 2012 года . Проверено 30 июля 2007 г.
  23. ^ "Libsafe на FSF.org" . Проверено 20 мая 2007 г.
  24. ^ «StackGuard: автоматическое адаптивное обнаружение и предотвращение атак переполнения буфера, Коуэн и др.» (PDF) . Архивировано (PDF) из оригинала 9 октября 2022 г. Проверено 20 мая 2007 г.
  25. ^ "ProPolice в X.ORG" . Архивировано из оригинала 12 февраля 2007 года . Проверено 20 мая 2007 г.
  26. ^ «Обход аппаратного предотвращения выполнения данных Windows» . Архивировано из оригинала 30 апреля 2007 г. Проверено 20 мая 2007 г.
  27. ^ «12-й симпозиум по безопасности USENIX - Технический документ» . www.usenix.org . Проверено 3 апреля 2018 г.
  28. ^ «Защита от уловок указателя (вроде!)» . msdn.com . Архивировано из оригинала 2 мая 2010 г. Проверено 3 апреля 2018 г.
  29. ^ «USENIX — Ассоциация передовых вычислительных систем» (PDF) . www.usenix.org . Архивировано (PDF) из оригинала 9 октября 2022 г. Проверено 3 апреля 2018 г.
  30. ^ «Защита от уловок указателя (Redux)» . msdn.com . Архивировано из оригинала 19 декабря 2009 г. Проверено 3 апреля 2018 г.
  31. ^ «PaX: Домашняя страница команды PaX» . Проверено 3 июня 2007 г.
  32. ^ "KernelTrap.Org". Архивировано из оригинала 29 мая 2012 г. Проверено 3 июня 2007 г.
  33. ^ «Патч ядра Openwall Linux 2.4.34-ow1» . Архивировано из оригинала 19 февраля 2012 г. Проверено 3 июня 2007 г.
  34. ^ «Microsoft Technet: Предотвращение выполнения данных» . Архивировано из оригинала 22 июня 2006 г. Проверено 30 июня 2006 г.
  35. ^ «BufferShield: предотвращение использования переполнения буфера для Windows» . Проверено 3 июня 2007 г.
  36. ^ "Защитник стека NGSec" . Архивировано из оригинала 13 мая 2007 г. Проверено 3 июня 2007 г.
  37. ^ "PaX на GRSecurity.net" . Проверено 3 июня 2007 г.
  38. ^ «Эксплоитант — Информация и руководства по безопасности» . Проверено 29 ноября 2009 г.
  39. ^ Ларошель, Дэвид; Эванс, Дэвид (13 августа 2001 г.). «Статическое обнаружение вероятных уязвимостей переполнения буфера». Симпозиум USENIX по безопасности . 32 .
  40. ^ «Исследование планирования технологий компьютерной безопасности» (PDF) . п. 61. Архивировано из оригинала (PDF) 21 июля 2011 г. Проверено 2 ноября 2007 г.
  41. ^ «« Экскурсия по червю » Донна Сили, Университет Юты» . Архивировано из оригинала 20 мая 2007 г. Проверено 3 июня 2007 г.
  42. ^ "Архив списка рассылки по безопасности Bugtraq" . Архивировано из оригинала 1 сентября 2007 г. Проверено 3 июня 2007 г.
  43. ^ ""Разбивание стека ради развлечения и прибыли" Алеф Один" . Проверено 5 сентября 2012 г.
  44. ^ «Цифровая безопасность eEye». Архивировано из оригинала 20 июня 2009 г. Проверено 3 июня 2007 г.
  45. ^ «Бюллетень по безопасности Microsoft Technet MS02-039» . Майкрософт . Архивировано из оригинала 7 марта 2008 г. Проверено 3 июня 2007 г.
  46. ^ «Хакер взламывает защиту Xbox без мод-чипа» . Архивировано из оригинала 27 сентября 2007 г. Проверено 3 июня 2007 г.

Внешние ссылки