Как уменьшить переполнение буфера

В том случае, если небезопасная функция оставляет открытой возможность переполнения, не все потеряно. В настоящее время предпринимаются шаги по обнаружению этих уязвимостей во время компиляции и выполнения. При запуске программы компиляторы часто создают случайные значения, известные как канарейки, и помещают их в стек после каждого буфера. Подобно шахтерским птицам, в честь которых они названы, эти канарейки знаменуют опасность. Проверка значения канарейки относительно ее исходного значения может определить, произошло ли переполнение буфера. Если значение было изменено, программа может быть закрыта или перейти в состояние ошибки вместо того, чтобы продолжить работу с потенциально измененным обратным адресом. Некоторые современные операционные системы обеспечивают дополнительную защиту в виде неисполняемых стеков и рандомизации компоновки адресного пространства (ASLR). Неисполняемые стеки (например, Предотвращение Выполнения Данных [DEP]) помечают стек и в некоторых случаях другие структуры как области, где код не может быть выполнен. Это означает, что злоумышленник не может внедрить код эксплойта в стек и ожидать его успешного запуска. ASLR был разработан для защиты от возвратно-ориентированного программирования (обходной путь к неисполняемым стекам, где существующие фрагменты кода связываются вместе на основе смещений их адресов в памяти). Он работает путем рандомизации ячеек памяти структур, так что их смещения труднее определить. Если бы эта защита существовала в конце 1980-х, червя Морриса можно было бы предотвратить. Это связано с тем, что он частично функционировал, заполняя буфер в протоколе UNIX fingerd кодом эксплойта, а затем переполняя этот буфер, чтобы изменить обратный адрес, чтобы указать на буфер, заполненный кодом эксплойта. ASLR и DEP сделали бы более трудным определение адреса, на который нужно указать, если бы не сделали эту область памяти полностью неисполняемой.

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