abdul-kalam2000/retbleed-speculative-execution-pocВоспроизведение микроархитектурной атаки Retbleed (CVE-2022-29900/29901) в gem5. Переполнение RSB, утечка через побочный канал Flush+Reload и проверенная митигация lfence.
Практическое воспроизведение Retbleed (CVE-2022-29900 / CVE-2022-29901) — микроархитектурной атаки 2022 года, которая сломала защиту «Retpoline», доказав, что инструкции ret, долгое время считавшиеся безопасными, могут быть перехвачены, когда буфер стека возвратов (RSB) процессора переполняется.
Этот проект моделирует полный жизненный цикл атаки на модели x86-процессора с внеочередным исполнением в gem5: вызывает переполнение RSB, утекает секретные данные побайтово через кэш-сайд-канал Flush+Reload, а затем проверяет программную митигацию (lfence), которая закрывает утечку.
Курсовой проект — Advanced Computer Architecture, осень 2025, CUNY City College Авторы: Abdul Kalam Mansoor и Rebiha Selmani
Атаки в стиле Spectre показали, что спекулятивное исполнение оставляет побочные эффекты на уровне кэша, даже когда процессор «отменяет» неверное предсказание. Отраслевое решение — Retpoline — заменило опасные косвенные переходы инструкциями ret, исходя из предположения, что возвраты безопасно предсказываются из небольшого аппаратного стека (RSB). Retbleed показал, что это предположение ложно: исчерпайте RSB глубокой рекурсией, и процессор молча переключится на тот же небезопасный предсказатель, которого Retpoline был призван избежать.
| Этап | Что происходит |
|---|---|
| 1. Триггер | rsb_deep_call() рекурсивно вызывается на 32 уровня вглубь, переполняя RSB из 16 записей. Когда рекурсия разворачивается, RSB пуст. |
| 2. Откат | С пустым RSB процессор переключается на буфер целей переходов (BTB) для предсказания цели ret — который атакующий может отравить. |
| 3. Гаджет | Перехваченный спекулятивный путь исполняет gadget(), который читает байт секретного пароля и использует его как индекс в probe_array, подтягивая одну страницу этого массива в кэш. |
| 4. Шпион Flush+Reload | Перед атакой каждая страница probe_array вытесняется из кэша (_mm_clflush). После закрытия спекулятивного окна программа замеряет время доступа к каждому возможному значению байта (__rdtscp) — то, которое возвращается быстро (попадание в кэш), раскрывает секретный байт. |
Повторение этого для каждого байта ROOT_PASSWORD восстанавливает весь секрет, ни разу архитектурно не вызывая gadget().
| Режим | Задержка доступа | Результат |
|---|---|---|
Уязвимый (SECURE_MODE не определён) | ~49 циклов (попадание в кэш) | Секрет утёк побайтово, подтверждено красными индикаторами HIT! |
Пропатченный (SECURE_MODE определён, внедрён _mm_lfence()) | >150 циклов (промах кэша / шум) | Атака проваливается — вывод показывает SAFE / Found: ??? |
lfence заставляет процессор разрешить адрес возврата до того, как сможет исполниться любая последующая инструкция, схлопывая спекулятивное окно прежде, чем гаджет вообще коснётся памяти, зависящей от секрета.
src/
retbleed.c # Full PoC: trigger, gadget, Flush+Reload spy, and lfence mitigation (toggle via SECURE_MODE)
docs/
Retbleed_Report.pdf # Full written report: methodology, related work, gem5 setup, results
Retbleed_Attack_Demonstration.pptx # Slide deck used to present the project
PoC был собран и измерен под gem5 (DerivO3CPU, модель с внеочередным исполнением — требуется, поскольку модели с последовательным исполнением не реализуют спекулятивное исполнение):
gcc -O0 -static -o retbleed src/retbleed.c
./build/X86/gem5.opt configs/deprecated/example/se.py \
--cpu-type=DerivO3CPU --caches --l2cache \
--l1d_size=64kB --l1i_size=64kB --cmd=retbleed
Чтобы переключаться между уязвимым и пропатченным поведением, закомментируйте/раскомментируйте эту строку в начале retbleed.c:
#define SECURE_MODE
Код использует настоящие x86-интринсики (
_mm_clflush,__rdtscp,_mm_lfence) и также может быть скомпилирован и запущен нативно на x86-оборудовании (gcc -O0 -o retbleed src/retbleed.c) для более быстрой демонстрации — результаты будут зависеть от собственных митигаций хост-процессора (eIBRS, патчи микрокода и т. д.), что само по себе служит полезной иллюстрацией того, насколько тщательно этот класс ошибок был пропатчен с 2022 года.
lfence) показали накладные расходы производительности 14–39% на затронутом оборудовании.