Бинарные уязвимости/Переполнение стека

Адресное пространство процесса

Пример содержимого адресного пространства процесса на x86

Адресное пространство процесса на x86/amd64 - это совокупность виртуальных адресов, доступная программе. Размер адресного пространства на x86 без дополнительных способов расширения - 4 Гб, он разделённый на kernel-space (2/1 Гб) и user-space (2/3 Гб). На x86-64 размер адресного пространства 2**48 - старшие 16 бит адреса все равны или 0, или 1. Такие адреса называются каноничными, все другие - неканоничными. В случае попытки обращения к неканоничному адресу возникает general protection exception (#GP). В случае x86-64 каноничность адресов можно использовать при проведении анализа содержимого памяти (так адрес из адресного пространства ядра будет иметь префикс 0xFFF, а из пользовательского - 0x000).

В *nix в user-space части адресного пространства содержится:
- запускаемый исполняемый файл
- динамические *.so библиотеки
- mmap() области (анонимные аллокации и отмапленные файлы)
- стек
- куча
- отмапленные из ядра области (vsyscall/vvar/vdso)
- различные служебные структуры

В pwndbg/gef/peda содержимое адресного пространства можно посмотреть с помощью команды vmmap:

В gdb можно использовать команду info proc map, а без отладчика содержимое можно посмотреть через файловую систему /proc с помощью команды cat /proc/<self>/maps.

Stack buffer overflow

Переполнение буфера в стеке происходит, когда программа должным образом не проверяет размер буфера, выделенного на стеке, при записи в него. Например, так делают известные функции gets, strcpy. Рассмотрим пример функции с таким типом уязвимости:

void foo(char* arg){
    int is_admin = 0;
    char buffer[256];

    strcpy(buffer, arg);
    printf("Hello, %s\n", buffer);

    if (is_admin == 0x1337) {
        print_passwrd();
    }
}

Устройство стека

В данной функции определяется локальная переменная is_admin и локальный массив buffer, размещающиеся на стеке. Функция strcpy копирует arg, переданный во втором аргументе, в buffer до тех пор пока не встретит в ней нулевой байт. При этом сам нулевой байт также будет скопирован. Чтобы понять, почему это может быть опасно, нужно рассмотреть содержимое стекового кадра функции foo. Предположим, что мы скомпилировали данный код в 64-битную программу без оптимизации и соглашение о вызовах функции - cdecl. Тогда стековый кадр будет выглядеть так:

На данной схеме стрелочкой показано направление роста стека в адресном пространстве (от старших к младшим адресам). Далее последовательно в стеке располагаются:
- аргумент функции foo
- адрес возврата - адрес, на который перейдет управление после окончания исполнения функции foo
- значение регистра ebp, являющееся указателем стекового кадра вызывающей foo функции
- опциональный паддинг (обычно используется, что локальные аргументы были выравнены по 16 байт)
- локальный массив local

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