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

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

Переполнение буфера на стеке чаще влияет на выполнение программы, чем переполнение буфера в куче, поскольку стек содержит адреса возврата всех активных вызовов функций. Тем не менее существуют и похожие реализации защиты для предотвращения переполнений в куче. По данным MITRE CWE Top 25 за 2025 год, переполнение буфера на стеке (CWE-121) и в куче (CWE-122) остаются одними из самых распространённых и опасных программных слабостей^[4].

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

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

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

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

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

Современные стратегии предотвращения уязвимостей также включают концепцию «Secure by Design», продвигаемую NIST и CISA, которая заключается в системном предотвращении уязвимостей на этапе разработки путём перехода на языки программирования с безопасной работой с памятью.

Канарейки, canary words или stack cookies — это известные значения, размещаемые между буфером и управляющими данными на стеке для обнаружения переполнения буфера. При переполнении буфера первым повреждается именно канарейка, а неудачная верификация контрольного значения сигнализирует об ошибке переполнения, что позволяет, например, прервать выполнение или аннулировать повреждённые данные. Не следует путать канарейку с сторожевым значением.

Название отсылает к исторической практике: канареек использовали в шахтах, чтобы раньше людей ощущать ядовитые газы — так канарейки служили биологической системой раннего предупреждения. Также термин stack cookie («стековая печенька») подчёркивает, как повреждение данного значения образует «поломанную печеньку».

Выделяют три типа канареек: terminator, random и random XOR. Современные реализации StackGuard поддерживают все три типа; ProPolice реализует terminator и random-канарейки.

Основными методами обхода канареек являются утечка информации и атаки полным перебором (brute-force) в дочерних процессах при вызове fork. Для защиты от подобных атак применяются перерандомизация канарейки при fork и изоляция эталонного значения в недоступной для пользователя памяти.

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

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

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

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

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

Контроль границ (bounds checking) — это компиляторная технология, в которой для каждого выделенного участка памяти поддерживается информация о границах и производится контроль всех операций доступа к памяти в рантайме. Для языков C и C++ контроль границ может выполняться как на стадии вычисления указателя^[6], так и при разыменовании указателя^[7][8][9].

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

Современные компиляторы (например, LLVM и Rust) используют статический анализ (в частности, Scalar Evolution) для исключения избыточных проверок границ (bounds check elimination) в циклах, что повышает производительность без ущерба для безопасности. Кроме того, в Clang разрабатывается флаг -fbounds-safety для комплексной проверки границ в языке C.

Тегирование^[10] — компиляторная или аппаратная (требует тегированная архитектура) методика, позволяющая пометить тип данных в памяти для осуществления контроля типов. За счёт маркировки отдельных областей памяти как невыполняемых предотвращается внедрение и исполнение кода в выделенной под данные памяти. Помимо этого можно помечать отдельные блоки как невыделенные, предотвращая переполнения буфера.

Исторически тегирование использовалось в реализации высокоуровневых языков программирования^[11]; при поддержке операционной системы возможно и обнаружение переполнений буфера. Пример аппаратной реализации — NX bit, поддерживаемый процессорами Intel, AMD и ARM.

К современным аппаратным реализациям тегирования относится механизм Intel Linear Address Masking (LAM), который позволяет использовать старшие биты 64-битного указателя для хранения метаданных (тегов), что аппаратно ускоряет обнаружение переполнений буфера.

Современные аппаратные архитектуры предоставляют встроенные механизмы для защиты от переполнения буфера и контроля целостности потока выполнения^[12].

В архитектуре RISC-V реализовано несколько уровней защиты:

• Защита физической памяти (PMP) — механизм, позволяющий задавать права доступа (чтение, запись, исполнение) для различных регионов физической памяти, что обеспечивает изоляцию критически важных областей от пользовательских приложений^[13].
• Расширения для контроля целостности потока выполнения (CFI):

Zicfiss — реализует аппаратный теневой стек для защиты обратных переходов. При вызове функции адрес возврата дублируется в защищённую область памяти, а перед возвратом сверяется с основным стеком, предотвращая подмену адреса^[14].^[15] Zicfilp — обеспечивает защиту прямых переходов, гарантируя, что передача управления возможна только на специально разрешённые участки кода («посадочные площадки»)^[14].^[15]

Фундаментальным подходом к обеспечению безопасности памяти является архитектура CHERI (Capability Hardware Enhanced RISC Instructions). Она заменяет традиционные указатели на аппаратно-защищённые «возможности» (capabilities). Такие структуры данных объединяют адрес в памяти с точными границами выделенного участка и правами доступа. Любая операция с памятью аппаратно проверяется на соответствие этим границам и разрешениям, что делает невозможным выход за границы буфера^[16].

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

С целью структурного исключения ошибок управления памятью Rust внедряется в ядро Linux для разработки драйверов и подсистем. В апреле 2026 года, с выходом ядра Linux версии 7.0, статус поддержки языка для этих задач был изменён на «полностью поддерживаемый»^[17]. Использование системы типов и механизма проверок на этапе компиляции позволяет избежать целых классов уязвимостей, характерных для языка C, таких как переполнение буфера, разыменование нулевых указателей и использование памяти после освобождения^[18].

Технология MiraclePtr, разработанная компанией Google для браузера Chrome, предназначена для защиты от уязвимостей, связанных с использованием памяти после её освобождения (use-after-free). Она представляет собой обёртку над «сырыми» указателями, которая выполняет дополнительные проверки. При попытке обращения к уже освобождённой памяти MiraclePtr аварийно завершает работу процесса, предотвращая тем самым эксплуатацию уязвимостей^[19].^[20]

Первая практическая реализация защиты от разрушения стека появилась в технологии StackGuard в 1997 году; публикация о ней состоялась на конференции USENIX Security Symposium в 1998 году^[21]. StackGuard был реализован как патч к x86 бэкенду GCC 2.7. С 1998 по 2003 год поддерживался и развивался для дистрибутива Linux Immunix, включая реализации всех видов канареек. В 2003 году предлагался к включению в GCC 3.x, но этого не произошло.

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

В 2005 году инженеры Red Hat выявили проблемы в ProPolice и заново реализовали защиту для включения в GCC 4.1^[23][24]. Введены флаги -fstack-protector (защита только уязвимых функций) и -fstack-protector-all (защита всех функций)^[25].

В 2012 году инженеры Google реализовали флаг -fstack-protector-strong, который даёт баланс между безопасностью и производительностью^[26]. Этот флаг входит в GCC начиная с версии 4.9^[27].

Все пакеты Fedora компилируются с -fstack-protector с версии Fedora Core 5 и с -fstack-protector-strong с Fedora 20^[28][29]. Большинство пакетов Ubuntu собирается с этим флагом с версии 6.10^[30]. Все пакеты Arch Linux с 2011 года используют -fstack-protector^[31], а с 4 мая 2014 года — -fstack-protector-strong. В Debian 13 и 14 флаг -fstack-protector-strong включён по умолчанию через dpkg-buildflags, а во FreeBSD 14 и 15 по умолчанию используется базовая защита SSP, а не strong. В ряде ОС (например, OpenBSD^[32], Hardened Gentoo^[33] и DragonFly BSD) защита является стандартной.

StackGuard и ProPolice не защищают от переполнений внутри структур, ведущих к перезаписи указателей функций. ProPolice старается разместить такие структуры перед указателями. Механизм отдельной защиты указателей — PointGuard^[34], который реализован в Microsoft Windows^[35].

В версии GCC 15 был добавлен атрибут counted_by для защиты гибких членов массива (Flexible Array Members, FAM) внутри структур, что позволяет более точно отслеживать выход за пределы выделенной памяти.

Кроме того, для защиты от перезаписи адреса возврата поддерживается генерация кода для аппаратного Shadow Stack (Intel CET) и программного механизма ShadowCallStack^[1].^[2]

Компиляторный пакет Microsoft реализует защиту от переполнения буфера с версии 2003 года с помощью ключа /GS, по умолчанию включённого с версии 2005. Отключить защиту можно флагом /GS-.

Актуальной и рекомендуемой технологией защиты целостности потока управления в Windows является Control Flow Guard (CFG). Более строгая технология eXtended Flow Guard (XFG) была отменена.

Защиту от разрушения стека можно активировать флагом -qstackprotect.

Clang поддерживает те же флаги -fstack-protector, что и GCC^[36], а также более гибкую систему «безопасного стека» (-fsanitize=safe-stack), не оказывающую существенного влияния на производительность^[37]. Clang предоставляет три детектора переполнения буфера: AddressSanitizer (-fsanitize=address)^[8], UBSan (-fsanitize=bounds)^[38], а также неофициальный SafeCode (разработан до LLVM 3.0)^[39], который был заброшен и не поддерживается в современных версиях LLVM.

Эти системы различаются по производительности, расходу памяти и обнаруживаемым классам ошибок. В ряде ОС (например, OpenBSD)^[40] защита стека включена по умолчанию.

В компиляторе реализована технология ShadowCallStack, активно используемая в Android на архитектуре AArch64, а в iOS применяется аппаратная технология Pointer Authentication Codes (PAC). Кроме того, Clang поддерживает программные и аппаратные механизмы контроля целостности потока выполнения (Control-Flow Integrity, CFI)^[3].

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

Fail-Safe C^[9] — это свободный компилятор ANSI C с контролем границ на основе толстых указателей и объектно-ориентированным доступом к памяти^[41].

Технология StackGhost, изобретённая Майком Франценом, использует аппаратные возможности архитектуры SPARC (отложенные spilling/filling регистровых окон), чтобы обнаруживать изменения указателей возврата и защищать все приложения без изменений исходного кода. Производительность почти не страдает (меньше 1%). Поддержка была интегрирована и оптимизирована в OpenBSD/SPARC.