Какие ошибки могут возникнуть при использовании стека

Стек (или магазин) — структура данных в программировании, работающая по принципу магазина с патронами: последний помещеннный в него объект, обрабатывается первым.

Приработе со стекам часто приходится сталкиваться с двумя типичными ошибками: переполненем стека и опустошением стека.

Переполнение стека (stack overflow) — одна из типичных ошибок при работе со стеком, состоящая в попытке добавить в стек элемент, когда память, отведенная для хранения стека полностью занята.

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

Если стек моделируется на связанном списке, то переполнение стека обычно возникает только при исчерпании доступной для программы оперативной памяти. В этом случае программа завершается с диагностикой «Недостаточно памяти».

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

Опустошение стека (stack underflow) — другая типичная ошибка при работе со стеком, состоящая в попытке извлечь значение пустого стека.

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

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

Причиной опустошения стека обычно является зацикливание на участке программы, где количество операций извлечения из стека превышает количество операций добавления в стек. Другая причина переполнения стека — несогласованность операций пополнения и извлечения из стека. Например, если подпрограмма ожидает получить больше параметров, чем ей передается при вызове через стек.

Чтобы избегать ошибок при работе со стеком нужно следовать двум правилам.

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

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

Описанные правила безопасности приводят к тому, что программный код оказывается перегружен проверками. По этой причине более эффективным методом является уведомление об ошибках в работе со стеком при помощи механизма исключений или прерываний (например, конструкция  try … throw в языке С++).

Дополнительно в базе данных Генона: 

• Что такое стек в программировании?
• Для чего используются указатели в программировании?

Ссылки по теме:

• cyberforum.ru — реализация стека на С++ с использованием исключений 
• ru.wikipedia.org — Википедия: Переполнение буфера
• codenet.ru — рассматривается уязвимость Windows за счет использования переполнения стека  
• sdteam.com — статья «Переполнения стека»
• xakep.ru — статья «Переполнение буфера в стеке», Хакер, №2, 2003

Информатика. 11 класс. Углубленный уровень. В 2 ч. Поляков К.Ю., Еремин Е.А. § 42. Стек, очередь, дек

Вопросы и задания

1. Что такое стек? Какие операции со стеком разрешены?
2. Как используется системный стек при выполнении программ?
3. Какие ошибки могут возникнуть при использовании стека?
4. В каких случаях можно использовать обычный массив для моделирования стека?
5. Как построить стек на основе динамического массива?
6. Почему при передаче стека в подпрограммы, приведённые в параграфе, соответствующий параметр должен быть изменяемым?
7. Что такое очередь? Какие операции она допускает?
8. Приведите примеры задач, в которых можно использовать очередь.

Подготовьте сообщение
а) «Моделирование стека и очереди в языке Си»
б) «Моделирование стека и очереди в языке Python»
в) «Моделирование очереди с помощью стеков»
г) «Очередь с приоритетом»

Задача

1. Напишите программу, которая «переворачивает» массив, записанный в файл, с помощью стека. Размер массива неизвестен. Все операции со стеком вынесите в отдельный модуль.

2. Напишите программу, которая вычисляет значение арифметического выражения, записанного в постфиксной форме. Выражение вводится с клавиатуры в виде символьной строки.

3. Напишите программу, которая проверяет правильность скобочного выражения с четырьмя видами скобок: (), [], {} и <>. Все операции со стеком вынесите в отдельный модуль.

*4. Найдите в литературе или в Интернете алгоритм перевода арифметического выражения из инфиксной формы в постфиксную и напишите программу, которая решает эту задачу.

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

*6. Перепишите программу из задачи 5 — используйте статический массив для организации очереди. Считайте, что в очереди может быть не более 100 элементов. Предусмотрите обработку ошибки «очередь переполнена».

*7. Напишите программу решения задачи о заливке области, помечая при этом точки, добавленные в очередь, чтобы не добавлять их повторно. В чём преимущества и недостатки такого алгоритма?

To describe this, first let us understand how local variables and objects are stored.

Local variable are stored on the stack:

If you looked at the image you should be able to understand how things are working.

When a function call is invoked by a Java application, a stack frame is allocated on the call stack. The stack frame contains the parameters of the invoked method, its local parameters, and the return address of the method. The return address denotes the execution point from which, the program execution shall continue after the invoked method returns. If there is no space for a new stack frame then, the StackOverflowError is thrown by the Java Virtual Machine (JVM).

The most common case that can possibly exhaust a Java application’s stack is recursion. In recursion, a method invokes itself during its execution. Recursion is considered as a powerful general-purpose programming technique, but it must be used with caution, to avoid StackOverflowError.

An example of throwing a StackOverflowError is shown below:

StackOverflowErrorExample.java:

public class StackOverflowErrorExample {

    public static void recursivePrint(int num) {
        System.out.println("Number: " + num);
        if (num == 0)
            return;
        else
            recursivePrint(++num);
        }

    public static void main(String[] args) {
        StackOverflowErrorExample.recursivePrint(1);
    }
}

In this example, we define a recursive method, called recursivePrint that prints an integer and then, calls itself, with the next successive integer as an argument. The recursion ends until we pass in 0 as a parameter. However, in our example, we passed in the parameter from 1 and its increasing followers, consequently, the recursion will never terminate.

A sample execution, using the -Xss1M flag that specifies the size of the thread stack to equal to 1 MB, is shown below:

Number: 1
Number: 2
Number: 3
...
Number: 6262
Number: 6263
Number: 6264
Number: 6265
Number: 6266
Exception in thread "main" java.lang.StackOverflowError
        at java.io.PrintStream.write(PrintStream.java:480)
        at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
        at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
        at sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:104)
        at java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:185)
        at java.io.PrintStream.write(PrintStream.java:527)
        at java.io.PrintStream.print(PrintStream.java:669)
        at java.io.PrintStream.println(PrintStream.java:806)
        at StackOverflowErrorExample.recursivePrint(StackOverflowErrorExample.java:4)
        at StackOverflowErrorExample.recursivePrint(StackOverflowErrorExample.java:9)
        at StackOverflowErrorExample.recursivePrint(StackOverflowErrorExample.java:9)
        at StackOverflowErrorExample.recursivePrint(StackOverflowErrorExample.java:9)
        ...

Depending on the JVM’s initial configuration, the results may differ, but eventually the StackOverflowError shall be thrown. This example is a very good example of how recursion can cause problems, if not implemented with caution.

How to deal with the StackOverflowError

1. The simplest solution is to carefully inspect the stack trace and
   detect the repeating pattern of line numbers. These line numbers
   indicate the code being recursively called. Once you detect these
   lines, you must carefully inspect your code and understand why the
   recursion never terminates.

2. If you have verified that the recursion
   is implemented correctly, you can increase the stack’s size, in
   order to allow a larger number of invocations. Depending on the Java
   Virtual Machine (JVM) installed, the default thread stack size may
   equal to either 512 KB, or 1 MB. You can increase the thread stack
   size using the -Xss flag. This flag can be specified either via the
   project’s configuration, or via the command line. The format of the
   -Xss argument is:
   -Xss<size>[g|G|m|M|k|K]

Переполнение стека — распространенная проблема в компьютерном программировании, которая может привести к непредсказуемому поведению и уязвимостям безопасности в программах на C/C++. Для разработчиков важно иметь возможность выявлять и устранять потенциальные проблемы переполнения стека, чтобы их можно было избежать или исправить до того, как они вызовут какие-либо проблемы. В этом сообщении блога мы рассмотрим некоторые способы обнаружения возможных проблем с переполнением стека в программах на C/C++.

Что такое переполнение стека?

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

Обнаружение переполнения стека:

Существует несколько методов обнаружения переполнения стека в программах на C/C++:

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

Как обнаружить потенциальные проблемы с переполнением стека?

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

1. Проверьте использование памяти программой

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

2. Анализ кода

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

3. Используйте инструмент проверки памяти

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

4. Использование анализатора стека

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

Заключение

Переполнение стека — распространенная проблема в компьютерном программировании, которая может привести к непредсказуемому поведению и уязвимостям безопасности в программах на C/C++. К счастью, разработчики могут обнаруживать и устранять потенциальные проблемы переполнения стека несколькими способами. Используя инструмент отладки памяти, такой как Valgrind, или инструмент статического анализа, разработчики могут выявлять и устранять потенциальные проблемы переполнения стека до того, как они вызовут какие-либо проблемы. Кроме того, анализаторы стека можно использовать для обнаружения того, когда программа использует слишком много памяти или когда она пытается получить доступ к памяти, которая недоступна в стеке.

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

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

Содержание

• 1 Использование переполнения буфера стека
• 2 Различия, связанные с платформой
  • 2.1 Растущие стеки
• 3 Схемы защиты
  • 3.1 Канарейки стека
  • 3.2 Неисполняемый стек
  • 3.3 Рандомизация
• 4 Примечательные примеры
• 5 См. Также
• 6 Ссылки

Использование буфера стека overflows

Канонический метод использования переполнения буфера на основе стека — перезапись адреса возврата функции указателем на данные, контролируемые злоумышленником (обычно в самом стеке). Это проиллюстрировано с помощью strcpy() в следующем примере:

#include void foo (char * bar) {char c [12]; strcpy (c, bar); // без проверки границ} int main (int argc, char ** argv) {foo (argv [1]); возврат 0; }

Этот код берет аргумент из командной строки и копирует его в локальную переменную стека c. Это отлично работает для аргументов командной строки меньше 12 символов (как вы можете видеть на рисунке B ниже). Любые аргументы длиной более 11 символов приведут к повреждению стека. (Максимальное количество безопасных символов на единицу меньше размера буфера здесь, потому что в языке программирования C строки заканчиваются нулевым байтовым символом. Таким образом, для ввода из двенадцати символов требуется тринадцать байтов для хранения, за вводом следует нулевым байтом контрольного значения. Нулевой байт затем завершается перезаписью области памяти, которая на один байт выходит за пределы буфера.)

Программный стек в foo ()с различными входами:

Обратите внимание, что на рисунке C выше, когда в командной строке указан аргумент размером более 11 байт foo ()перезаписывает данные локального стека, сохраненный кадр указатель, а главное — адрес возврата. Когда foo ()возвращает, он выталкивает адрес возврата из стека и переходит к этому адресу (т.е. начинает выполнять инструкции с этого адреса). Таким образом, злоумышленник перезаписал адрес возврата указателем на буфер стека char c [12], который теперь содержит данные, предоставленные злоумышленником. При фактическом использовании переполнения буфера стека строка «A» вместо этого будет шеллкодом, подходящим для платформы и желаемой функции. Если у этой программы были особые привилегии (например, бит SUID установлен для запуска от имени суперпользователя ), то злоумышленник мог использовать эту уязвимость, чтобы получить привилегии суперпользователя на уязвимой машине.

Злоумышленник также может изменить значения внутренних переменных, чтобы воспользоваться некоторыми ошибками. В этом примере:

#include #include void foo (char * bar) {float My_Float = 10.5; // Адрес = 0x0023FF4C char c [28]; // Addr = 0x0023FF30 // Напечатает 10.500000 printf ("My Float value =% f  n", My_Float); / * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~ Карта памяти: @: c выделенная память #: выделенная память My_Float * c * My_Float 0x0023FF30 0x0023FF4C | | @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@.com memcpy поместит 0x1010C042 (little endian) в значение My_Float. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~ * / memcpy (c, bar, strlen (bar)); // без проверки границ... // напечатает 96.031372 printf ("My Float value =% f  n", My_Float); } int main (int argc, char ** argv) {foo ("моя строка слишком длинная !!!!!  x10  x10  xc0  x42"); возврат 0; }

Различия, связанные с платформой

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

Растущие стеки

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

Схемы защиты

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

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

Стек канареек

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

Невыполняемый стек

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

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

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

Вариантом return-to-libc является возвратно-ориентированное программирование (ROP), которое устанавливает серию адресов возврата, каждый из которых выполняет небольшую последовательность выбранной машиной инструкции в рамках существующего программного кода или системных библиотек, последовательность которых заканчивается возвратом. Каждый из этих так называемых гаджетов выполняет простую манипуляцию с регистрами или аналогичное выполнение перед возвратом, и объединение их вместе достигает целей злоумышленника. Можно даже использовать «безвозвратное» программирование, ориентированное на возврат, используя инструкции или группы инструкций, которые ведут себя так же, как инструкция возврата.

Рандомизация

Вместо отделения кода от данных, другой метод смягчения последствий — введение рандомизации в область памяти исполняемой программы. Поскольку злоумышленнику необходимо определить, где находится исполняемый код, который можно использовать, либо предоставляется исполняемая полезная нагрузка (с исполняемым стеком), либо она создается с использованием повторного использования кода, например, в ret2libc или в программировании, ориентированном на возврат (ROP). Рандомизация структуры памяти, как концепция, не позволяет злоумышленнику узнать, где находится какой-либо код. Однако реализации обычно не все рандомизируют; обычно сам исполняемый файл загружается по фиксированному адресу, и, следовательно, даже когда ASLR (рандомизация разметки адресного пространства) комбинируется с невыполняемым стеком, злоумышленник может использовать эту фиксированную область памяти. Следовательно, все программы должны быть скомпилированы с использованием PIE (независимые от позиции исполняемые файлы), чтобы даже эта область памяти была рандомизирована. Энтропия рандомизации отличается от реализации к реализации, и достаточно низкая энтропия сама по себе может быть проблемой с точки зрения грубого форсирования пространства памяти, которое рандомизируется.

Примечательные примеры

• Червь Morris в 1988 г. частично распространился за счет использования переполнения буфера стека на сервере Unix finger. [1]
• Червь Witty в 2004 г. распространился, эксплуатируя переполнение буфера стека в Internet Security Systems BlackICE Desktop Agent. [2]
• Червь Slammer в 2003 г. распространился, эксплуатируя переполнение буфера стека на SQL-сервере Microsoft. [3]
• Червь Blaster в Распространение 2003 г. за счет использования переполнения буфера стека в службе Microsoft DCOM.
• Существует несколько примеров Wii, позволяющих запускать произвольный код в неизмененной системе.. «Сумеречный хак», который включает в себя длинное имя лошади главного героя в The Legend of Zelda: Twilight Princess и «Smash Stack» для Super Smash Bros. Brawl, который включает использование SD-карты для загрузки специально подготовленного файла в редактор игровых уровней. Хотя оба могут использоваться для выполнения любого произвольного кода, последний часто используется для простой перезагрузки самой Brawl с применением модификаций.

См. Также

• Рандомизация компоновки адресного пространства
• Переполнение буфера
• Стек вызовов
• Компьютерная безопасность
• ExecShield
• Защита исполняемого пространства
• Эксплойт (компьютерная безопасность)
• Атака форматной строки
• Переполнение кучи
• Целочисленное переполнение
• бит NX
• PaX
• Возврат-ориентированное программирование
• Linux с усиленной безопасностью
• Переполнение стека
• Нарушение хранилища
• Уязвимость (вычисления)

Ссылки