Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

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

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

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

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

Техническое описание [ править ]

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

Пример [ править ]

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

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

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

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

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

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

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

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

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

strlcpy ( A ,  «чрезмерно» ,  sizeof ( A ));

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

Эксплуатация [ править ]

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

Использование стека [ править ]

Технически подкованный пользователь может использовать переполнение стека буфера, чтобы манипулировать программой в своих интересах одним из нескольких способов:

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

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

Использование кучи [ править ]

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

Microsoft «s GDI + уязвимость в обработке JPEGs является примером опасности переполнения кучи может представить. [4]

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

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

Практические аспекты эксплуатации [ править ]

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

Техника саней NOP [ править ]

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

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

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

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

Переход к адресу, хранящемуся в регистровом методе [ править ]

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

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

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

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

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

Защитные контрмеры [ править ]

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

Выбор языка программирования [ править ]

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

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

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

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

Хорошо написанные и проверенные библиотеки абстрактных типов данных, которые централизуют и автоматически выполняют управление буфером, включая проверку границ, могут уменьшить возникновение и влияние переполнения буфера. Двумя основными типами данных строительных блоков в этих языках, в которых обычно происходит переполнение буфера, являются строки и массивы; таким образом, библиотеки, предотвращающие переполнение буфера в этих типах данных, могут обеспечить подавляющее большинство необходимого покрытия. Тем не менее, неправильное использование этих безопасных библиотек может привести к переполнению буфера и другим уязвимостям; и, естественно, любая ошибка в самой библиотеке является потенциальной уязвимостью. "Безопасные" реализации библиотеки включают " Лучшую строковую библиотеку" [17] Vstr [18] и Erwin. [19] OpenBSDБиблиотека C операционной системы предоставляет функции strlcpy и strlcat , но они более ограничены, чем полностью безопасные реализации библиотеки.

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

Защита от переполнения буфера [ править ]

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

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

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

Защита указателя [ править ]

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

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

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

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

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

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

  • PaX [30]
  • Exec Shield [31]
  • Openwall [32]

Новые варианты Microsoft Windows также поддерживают защиту исполняемого пространства, называемую предотвращением выполнения данных . [33] Фирменные надстройки включают:

  • BufferShield [34]
  • StackDefender [35]

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

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

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

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

Глубокая проверка пакетов [ править ]

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

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

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

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

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

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

Самая ранняя задокументированная враждебная эксплуатация переполнения буфера произошла в 1988 году. Это была одна из нескольких эксплойтов, использованных червем Морриса для распространения через Интернет. Используемая программа представляла собой службу в Unix под названием finger . [40] Позднее, в 1995 году, Томас Lopatic независимо друг от друга вновь открыли переполнение буфера и опубликовал свои выводы о Bugtraq списке рассылки безопасности. [41] Год спустя, в 1996 году, Элиас Леви (также известный как Алеф Уан) опубликовал в журнале Phrack статью «Разбивая стопку ради развлечения и прибыли», [42] Пошаговое введение в использование уязвимостей переполнения буфера на основе стека.

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

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

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

  • Миллиард смеется
  • Перечитывание буфера
  • Компьютерная безопасность
  • Конец файла
  • Переполнение кучи
  • Пинг смерти
  • Сканер портов
  • Атака с возвратом к libc
  • Операционная система, ориентированная на безопасность
  • Самомодифицирующийся код
  • Шелл-код
  • Переполнение буфера стека
  • Строка неконтролируемого формата

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

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

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

  • «Обнаружение и использование уязвимости удаленного переполнения буфера на FTP-сервере» от Raykoid666
  • "Разбивая стопку ради развлечения и прибыли" Алеф Уан
  • Герг, Исаак (2005-05-02). «Обзор и пример эксплойта переполнения буфера» (PDF) . Информационный бюллетень . Центр анализа информационных технологий . 7 (4): 16–21. Архивировано из оригинального (PDF) 27 сентября 2006 года . Проверено 17 марта 2019 .
  • Стандарты безопасного кодирования CERT
  • CERT Secure Coding Initiative
  • Безопасное кодирование на C и C ++
  • SANS: внутри атаки переполнения буфера
  • «Достижения в области переполнения смежной памяти» от Nomenumbra
  • Сравнение реализаций предотвращения переполнения буфера и слабых сторон
  • Дополнительные технические документы по безопасности о переполнении буфера
  • Глава 12: Написание эксплойтов III из сокетов, шелл-кода, портирования и кодирования: обратное проектирование эксплойтов и кодирование инструментов для специалистов по безопасности Джеймса К. Фостера ( ISBN 1-59749-005-9 ). Подробное объяснение того, как использовать Metasploit для разработки эксплойта переполнения буфера с нуля. 
  • Исследование планирования технологий компьютерной безопасности , Джеймс П. Андерсон, ESD-TR-73-51, ESD / AFSC, Hanscom AFB, Bedford, MA 01731 (октябрь 1972 г.) [NTIS AD-758 206]
  • «Переполнение буфера: анатомия эксплойта» от Nevermore
  • Безопасное программирование с помощью GCC и GLibc (2008 г.), Марсель Хольтманн
  • "Criação de Exploits com Buffer Overflor - Parte 0 - Um pouco de teoria" (2018), Хельвио Джуниор (M4v3r1ck)