1. Переполнения буферов
Переполнение буфера было задокументировано и осмыслено еще в 1972 году [1]. Данная уязвимость имеет место, когда программа выделяет в оперативной памяти буфер недостаточной длины либо при записи в буфер данных не проверяет (или некорректно проверяет) достаточность длины буфера. Считается, что переполнение буфера создаёт проблемы только в нативном коде (англ. native code) — т.е. в таких программах, которые используют набор инструкций процессора напрямую, без посредников [2]. С технической точки зрения языки программирования C и C++ являются «уязвимыми» языками программирования, поскольку в программах на этих языках программист может безнаказанно ссылаться на биты данных, отбрасывать и перемещать их, т.е. всячески манипулировать ими. В усовершенствованных языках программирования (наподобие Java и С#) применяются технологии «безопасности типов», и поэтому их применение намного предпочтительнее с точки зрения безопасности [5]. В качестве простейшего примера переполнения буфера рассмотрим следующую программу на языке C:
#include <stdio.h>
int main ()
{
char String[10];
puts ("Введите какой-нибудь текст:");
gets (String);
printf ("Вы ввели:%s", String);
}
Если пользователь вводит в программу строку длиной девять или менее символов (десятым символом является ноль, завершающий строку), программа работает корректно. Но если пользователь ввел с клавиатуры строку длиной десять символов или более, буфер, выделенный в стеке под переменную String, переполняется, и «хвост» введенной строки затирает данные, следующие в стеке непосредственно за буфером. Рассмотрим, как выглядит содержимое стека в данной программе после ввода пользователем строки корректной длины:
Если же пользователь введет строку некорректной длины, скажем, длины 20, заполнение стека будет иметь следующий вид:
Мы видим, что адрес возврата из функции main затерт введенными пользователем данными, и программа, продолжая работу, выполнит переход на адрес 0x30393837, по которому, скорее всего, размещается недоступная страница памяти. В результате программа аварийно завершит работу.
Если подать на вход программы специально подобранные данные, можно не только вызвать в программе ошибку, но и заставить программу выполнить некоторые действия, изначально не предусмотренные ее функциональностью. В частности, если программа имеет особые привилегии (например, запущена с правами root), злоумышленник может заменить адрес возврата на адрес шелл-кода (англ. shellcode, код запуска оболочки), что позволит ему исполнять команды в атакуемой системе с повышенными привилегиями [3].
Такая ошибка в программе, как внедрение кода через переполнение буфера, всегда нежелательна. Но серьёзной эту ошибку можно считать лишь в том случае, если она повышает привилегии пользователя. В частности, если внедрение кода происходит на локальной машине, это привилегий не повышает: пользователь и без этого может выполнять исполняемые файлы. Если же удаётся внедрить код через сеть, это уже повышение привилегий: у пользователя появилась возможность выполнять машинный код [11].
Начиная с Windows ХР SP2 в Windows включен специальный механизм DEP (Data Execution Prevention — «предотвращение выполнения данных», альтернативное название — NX, No Execute), защищающий от переполнения буферов. Основная идея DEP заключается в том, что страницы оперативной памяти, выделяемые процессу под глобальные данные, кучу и стеки потоков, получают атрибуты защиты PAGE_READWRITE вместо PAGE_ EXECUTEREADWRITE, как обычно.
Другой механизм защиты от переполнений буфера — введенная в Windows Vista система ASLR (Address Space Layout Randomization — «рандомизация размещения адресного пространства»). При включенной системе ASLR выбор адресов для отображения программных файлов, а также для выделения памяти под «кучу» и стек выполняются случайным образом. В результате в разных экземплярах одной и той же операционной системы и даже в разных загрузках одного и того же экземпляра операционной системы для одного и того же процесса карты распределения памяти будут совершенно различными. В результате использовать переполнение буфера для несанкционированной передачи управления на внедренный машинный код практически невозможно — для этого необходимо заранее знать адрес, по которому в памяти размещается этот код.
Но в феврале 2017 года команда исследователей из Амстердамского свободного университета представила миру JavaScript-атаку, которая способна обойти ASLR-защиту и представляет опасность для разных микропроцессорных архитектур, в том числе таких производителей, как Intel, AMD, ARM, Allwinner и Nvidia. Атака, как теперь принято, получила собственное имя: ASLR⊕Cache или AnC. Методика, созданная специалистами Амстердамского свободного университета, концентрируется вокруг блока управления памятью (memory management unit, MMU) который отвечает за управление доступом к памяти, запрашиваемым ЦП. Исследователи обнаружили, что компонент MMU, отвечающий за управление кешем, делит кеш с рядом недоверенных приложений, в том числе, с браузерами. Это означает, что нацелить на пространство совместно используемой памяти можно даже JavaScript-код, размещенный на специально подготовленной веб-странице. В результате атакующий сможет определить, где в виртуальной памяти расположены нужные ему данные, а затем продолжить атаку [4].