Кратко, с пояснениями.
Пример уязвимого фрагмента (C):
char buf[$16$];
gets(buf); // небезопасно — не проверяет длину ввода
Как работает переполнение (логика):
- В стеке функция выделяет локальный буфер размером $16$ байт и сохраняет служебные данные (сохранённый указатель кадра/RBP и адрес возврата).
- Структурно (упрощённо, на x86-64) стек может выглядеть так (адреса убывают вниз):
[higher addresses]
saved RBP
return address
buf (size $16$)
[lower addresses]
- Если пользователь запишет в buf больше чем $16$ байт, запись продолжит писать за границы буфера и перезапишет сначала соседние локальные переменные, затем saved RBP (если есть) и, в конце — return address.
- Чтобы контролировать адрес возврата, нужно записать как минимум $16$ байт буфера + размер saved RBP (обычно $8$ байт) = $16+8=24$ байта, после чего записать новые $8$ байт — желаемый адрес возврата. В payload это выглядит как: [padding $=24$ байта][новый адрес возврата].
Возможные последствия:
- Изменение адреса возврата → управление потоком программы → выполнение произвольного кода (RCE), если возможна запись и исполнение кода на стеке.
- Если исполнение на стеке запрещено (NX/DEP), атакующий может выполнить ret2libc/ROP-цепочку (используя уже существующий код).
- Коррупция других данных — изменение указателей, целостности программы → крахи (DoS) или тайные утечки данных.
- На Windows — перезапись SEH, на старых системах — простые инъекции шеллкода; современные атаки используют комбинации утечек информации и ROP.
Практические меры защиты (уровни: компилятор, рантайм, ОС):
1) Компилятор и утилиты сборки
- Stack canaries (stack protector): вставляют случайную «метку» между буфером и return address; при выходе проверяют её целостность и прерывают выполнение при нарушении. В gcc/clang: флаги $-fstack-protector$, $-fstack-protector-strong$.
- Функции-«укрепления»: $-D_{F}ORTIF{Y}_{S}OURCE=2$ (при оптимизациях) добавляет проверки для некоторых библиотечных вызовов (strcpy → memcpy с проверкой длины).
- AddressSanitizer (ASan): $-fsanitize=address$ — отлавливает переполнения в тестах/разработке.
- Включить PIE/PIE-exec и компоновку с RELRO: $-fPIE$ / $-pie$ и $-Wl,-z,relro,-z,now$ — облегчает ASLR и защищает GOT.
- Использовать безопасные API: strncpy/snprintf (правильно), или явно проверять длины; предпочитать языки с проверкой границ.
2) Операционная система / рантайм
- ASLR (Address Space Layout Randomization): рандомизация базовых адресов стека, heap, libc и т.д. Это затрудняет угадывание адресов для ROP/ret2libc. На 64‑битных системах энтропия обычно хорошая, на 32‑бит — слабее.
- NX / DEP (Non‑Executable memory): запрещает исполнение кода из областей данных (стек/куча). Не препятствует ROP.
- Full RELRO: фиксирует таблицы динамической привязки (GOT), препятствуя их перезаписи.
- SELinux / AppArmor / sandboxing: ограничивают последствия успешной эксплуатации.
- Kernel mitigations (например, PaX, grsecurity) для усиления ASLR, SMEP/SMAP и т.п.
3) Комбинации и практики разработки
- Defense in depth: сочетать canaries + NX + ASLR + PIE + RELRO + строгие проверки входных данных.
- Статический и динамический анализ (coverity, clang-tidy, fuzzing), code review.
- Минимизация привилегий (least privilege), запуск сервисов в chroot/контейнерах.
- В тестовой среде — включать ASan/UBsan и fuzzing, в продакшене — минимальный набор защит: stack protector, PIE, RELRO, NX, ASLR.
Ограничения защит и обходы
- ASLR можно обойти при наличии информационного утечки (узнать адрес libc/кучи/стека) или при низкой энтропии (32-бит).
- NX запрещает исполнение инъекционного шеллкода, но не ROP; ROP/ret2libc используются как обход.
- Stack canary предотвращает незаметную перезапись return address, но может быть обойдён, если canary прочитан (info leak) или если перезаписываются только указатели вне области защитной проверки.
Поэтому важна многослойная защита и удаление уязвимостей на уровне исходного кода (bounds checking, безопасные API, тесты).
Короткая практическая сводка действий:
- Исправлять код: проверять длины, использовать безопасные функции, предпочитать языки с проверкой границ.
- Собирать с $-fstack-protector-strong$, $-fPIE$/$-pie$, $-Wl,-z,relro,-z,now$, $-D_{F}ORTIF{Y}_{S}OURCE=2$.
- Включить в среде исполнения: NX, ASLR (sysctl), SELinux/AppArmor, sandboxing.
- Встраивать в процесс разработки: ASan/UBSan, fuzzing, статический анализ.
Если нужно, могу развернуто показать конкретный пример переполнения с расчётом смещения и пример защиты на уровне компиляции/сбора.