Пример уязвимости (реальный, упрощённый):
Код на C (уязвимая функция сервера):
```
void handle_client(int fd) {
char buf[$128$];
// небезопасно: читает произвольное число байт в буфер фиксированного размера
read(fd, buf, $1024$);
// далее обработка...
}
```
Почему это уязвимость. Если клиент отправит более $128$ байт, данные переполнят буфер на стеке и перезапишут соседние служебные поля: сохранённый фрейм указателя и адрес возврата. Стек (упрощённо) выглядит так:
buf ($128$ байт) | saved EBP ($4$ байта на $32$-bit) | return address ($4$ байта на $32$-bit)
Как эксплуатация приводит к удалённому выполнению кода:
- атакующий посылает полезную нагрузку: \([padding=\) \(\!128\) байт\()] + [новый return address] + [машинный код (shellcode)].
- при возврате функция загрузит перезаписанный return address и перейдёт на него, выполняя shellcode на стеке — получается RCE (remote code execution).
- современные варианты: если стэк неисполняем (NX), вместо shellcode ставят адреса функций libc (ret2libc) или цепочки гаджетов (ROP), чтобы вызвать system("/bin/sh") или выполнить произвольную логику без исполнения кода на стеке.
Современные техники защиты и их ограничения
1) NX / DEP (No-eXecute / Data Execution Prevention)
- Что делает: помечает страницы данных (стек, куча) как non-executable, запрещая исполнение shellcode прямо из них.
- Ограничения: не мешает переписать указатели и вызвать уже существующий исполняемый код; обходы — ret2libc, ROP. Если есть JIT или исполняемые данные (или отключён NX), защита не работает.
2) ASLR (Address Space Layout Randomization)
- Что делает: рандомизирует базовые адреса бинарника, библиотек, стека и кучи, чтобы атакующему было сложно предсказать адреса для перезаписи return address или для ret2libc/ROP.
- Ограничения:
- Энтропия зависит от архитектуры: на \(32\)-bit часто мала (десятки-биты), на $64$-bit гораздо больше (десятки/сотни бит). Примерные числа: $32$-bit ≈ $2^{16}$ или меньше, $64$-bit ≈ $2^{40}$ и выше.
- Информационные утечки (leaks) позволяют узнать базовые адреса и обойти ASLR.
- Частичные перезаписи адресов (byte-wise или half-word) и brute-force при удалённых сервисах с отсутствием лимитов на попытки также снижают эффективность.
3) Stack canaries (защитные «канарейки»)
- Что делает: компилятор вставляет случайное значение (canary) перед сохранённым адресом возврата; проверяет его перед возвратом — если переписано, программа аварийно завершается.
- Ограничения:
- Если атакующий может прочитать память (info leak), он узнает значение canary и сможет подделать нагрузку.
- Некоторые типы переполнений (например, переполнение в соседней области или non-contiguous overwrite) могут обойти проверку.
- Canaries защищают только против переписывания return address в типичном стеке; не мешают переписать указатели в куче или таблицы функций.
Комбинация и дополнительные меры
- Совместное использование NX + ASLR + canaries сильно повышает сложность эксплуатации, но не даёт абсолютной защиты: распространённый обход — информационные утечки + ROP.
- Доп. меры: PIE (Position Independent Executable) для рандомизации адреса самого бинаря; RELRO для защиты GOT; CFI (Control-Flow Integrity); Pointer Authentication (PAC на ARM64e); статический/динамический анализ, использование безопасных функций, переход на безопасные языки.
- Практика: уменьшить поверхность атаки (валидировать длину, использовать bounded APIs — e.g. fgets/recv with size), включить все аппаратные/ПО защиты, и устранять информационные утечки.
Краткий итог: простая переполнение буфера (перезапись return address) по-прежнему является прямым путём к RCE в отсутствии защит; NX/ASLR/canaries значительно затрудняют эксплуатацию, но каждую из них можно обойти при наличии утечек адресов или продвинутых техник (ret2libc, ROP, частичные перезаписи, brute-force при слабой энтропии).