NGINX Rift

RCE-эксплойт (Proof of concept) для CVE-2026-42945 — критического переполнения кучи в ngx_http_rewrite_module NGINX, появившегося ещё в 2008 году. Уязвимость позволяет неаутентифицированному удалённому злоумышленнику выполнить произвольный код на серверах, использующих директивы rewrite и set.

Этот форк расширяет исходный PoC цепочкой обхода ASLR, которая сочетает переполнение в NGINX с распространённым примитивом LFI/произвольного чтения файлов на том же хосте. Примитив чтения файлов используется для восстановления карт памяти воркеров nginx, libc и живого /proc/<worker>/mem, после чего удалённо вычисляются адрес system() и пригодные цели в куче.

Ранние версии этой лаборатории преднамеренно вызывали крах воркера nginx, чтобы сервис записал core dump, затем получали и разбирали этот core dump через примитив чтения файлов для восстановления чувствительного к ASLR состояния процесса, включая цели в куче. В этом репозитории coreless — это лишь сокращение для «без читаемого crash core dump»: текущий путь по умолчанию заменяет зависимость от crash core на чтение памяти через живой procfs, а сохранённый легаси-путь core-guided по-прежнему использует сгенерированный core dump воркера.

Эта уязвимость — вместе с тремя другими ошибками повреждения памяти (CVE-2026-42946, CVE-2026-40701, CVE-2026-42934) — была автономно обнаружена системой анализа безопасности depthfirst после одного клика по подключению исходного кода NGINX.

Хотите находить такие проблемы в своём коде? Попробуйте ту же систему на https://depthfirst.com/open-defense.

Суть уязвимости (TL;DR)

Скриптовый движок NGINX использует двухпроходный процесс: сначала вычисляется требуемый размер буфера, затем копируются данные. Флаг is_args устанавливается в основном движке, когда замена в rewrite содержит ?, но проход вычисления длины выполняется на свежеобнулённом под-движке. Таким образом:

• Проход вычисления длины видит is_args = 0 → возвращает исходную длину захвата.
• Проход копирования видит is_args = 1 → вызывает ngx_escape_uri с NGX_ESCAPE_ARGS, расширяя каждый байт, требующий экранирования, до 3 байт.

Копирование переполняет недостаточно большой буфер в куче управляемыми данными из URI. Эксплуатация использует межзапросный heap feng shui для повреждения указателя cleanup соседнего ngx_pool_t (распыляемого через тела POST-запросов, поскольку байты URI не могут содержать нулевые байты), перенаправляя его на поддельный ngx_pool_cleanup_s, который вызывает system() при уничтожении пула.

Подробнее об этой уязвимости читайте в нашем техническом разборе.

Затронутые и исправленные версии

Полное уведомление вендора: https://my.f5.com/manage/s/article/K000160932

Частный исследовательский форк: удалённая лабораторная цепочка с ASLR

Этот форк сохраняет исходный раскрывающий PoC нетронутым, но добавляет второе исследовательское направление, сосредоточенное на более реалистичном вопросе:

Можно ли эксплуатировать уязвимость на реальной виртуальной машине x86_64 Linux с включённым ASLR, не полагаясь на жёстко заданные смещения Docker/лаборатории?

Ответ в этом исследовательском форке — да, с важными ограничениями. Рабочие цепочки не отключают ASLR и не используют исходные жёстко заданные адреса кучи/libc. Вместо этого они получают состояние времени выполнения через доступные по HTTP примитивы на том же порту, а затем выбирают конечную цель в куче на основе удалённо полученных данных раскрытия.

Теперь есть два направления эксплойта с включённым ASLR, при этом путь coreless рассматривается как текущий лучший PoC:

• nginx_rifter.py: чистый, самодостаточный инструмент оценки и интегрированная точка входа эксплойта. Его метод эксплойта по умолчанию теперь — цепочка coreless через /proc/<nginx-worker>/mem.
• nginx_rifter_core_v2_1.py: сохранённая легаси-версия nginx_rifter.py с управлением через core. Она полезна для воспроизведения более старого исследовательского пути на основе crash core, протестированного на ВМ, но больше не является предпочтительным PoC.
• tools/proc_mem_coreless_exploit.py: более ранний автономный исследовательский стенд coreless. Его логика объединена в nginx_rifter.py; инструмент остаётся для повторения сырых экспериментов.

Целевая топология намеренно использует один порт:

• уязвимый маршрут: /api/...
• PHP-маршрут чтения локальных файлов: /lfi.php?file=...
• маршрут-подсказка phpinfo: /phpinfo.php
• жертвенное HTTP/2-соединение: тот же слушатель и воркер nginx
• проверка доказательства: файл-маркер читается обратно через PHP LFI-эндпоинт

Текущий путь coreless proc-mem выполняет следующие шаги высокого уровня:

1. Использует PHP LFI для чтения PHP-идентичности, pid-файлов nginx, карт памяти воркера nginx /proc/<pid>/maps и отображённого файла libc.
2. Разбирает целевой libc через LFI для вычисления абсолютного адреса system() для этого воркера.
3. Отправляет обычный трафик распыления/зондирования NGINX Rift, сохраняя состояние воркера живым.
4. Читает отображённые диапазоны из /proc/<worker>/mem через примитив чтения файлов.
5. Сканирует живую память на помеченные nonce структуры поддельной очистки и кандидатов cleanup-pool.
6. Использует ограниченные конечные кандидаты, полученные из живой памяти воркера, а не жёстко заданные смещения лаборатории или читаемые crash core.
7. Проверяет выполнение команд, читая вывод маркера через примитив чтения файлов.

Легаси-путь с управлением через core выполняет аналогичное вычисление базового адреса, затем намеренно вызывает крах воркера, читает сгенерированный core-файл через LFI и добывает из этого core распылённые слоты поддельной очистки. Это был полезный исследовательский мост, но он зависит от политики core dump и прав файловой системы, которые реже встречаются в конфигурациях по умолчанию.

Это не то же самое, что исходная детерминированная Docker-демонстрация. Путь x86_64 ВМ оставляет обычный Linux ASLR включённым и пересчитывает адреса, специфичные для процесса, при каждом запуске. Путь Docker coreless также оставляет ASLR включённым и устраняет необычное требование читаемого core, но зависит от поведения разрешений procfs, которое необходимо проверять для целевого класса.

Область применения и оговорки

Этот форк — контролируемая исследовательская лаборатория. Цепочки с включённым ASLR опираются на строгие условия, которые не являются универсальными предположениями для продакшена:

• PHP должен предоставлять полезный примитив чтения локальных файлов.
• Для пути coreless proc-mem по умолчанию PHP должен уметь читать карты /proc/<pid>/maps воркера nginx с тем же UID, отображённый libc и /proc/<pid>/mem на больших отображённых смещениях.
• Для легаси-пути с управлением через core PHP должен уметь читать карты /proc/<pid>/maps воркера nginx с тем же UID, отображённый libc и сгенерированный core воркера.
• HTTP/2 должен быть включён на том же слушателе nginx, чтобы обеспечить цель очистки пула соединений, используемую финальной цепочкой.

phpinfo() и /proc/<pid>/maps достаточны для восстановления базовых адресов PIE/libc, но сами по себе недостаточны для восстановления точного объекта/окна в куче, необходимого для этого эксплойта. Старая цепочка использовала читаемый crash core для финального раскрытия. Текущая цепочка по умолчанию использует /proc/<worker>/mem вместо этого, что ближе к реальному последствию произвольного чтения файлов в развёртываниях с одинаковым UID, поскольку раскрывает живую память воркера без изменения политики core dump.

Важные оставшиеся ограничения:

• /proc/<pid>/mem ограничен ptrace. Это сработало в Docker-лаборатории и при проверке с одинаковым UID против модели официального образа nginx:stable, но процессы с другими UID должны давать сбой при защите procfs по умолчанию.
• Примитив чтения файлов должен поддерживать большие смещения или эквивалентный API диапазонов.
• Повторное тестирование пути proc-mem на реальной Ubuntu VM всё ещё ожидается.
• Прямая утечка памяти из ответов nginx без LFI не найдена. Пассивное отражение, зондирование redirect/header/body, начальный замер over-read через отложенный прокси и проверка исходников с помощью SSRF не дали раскрытия, значимого для ASLR.

Текущие инструменты

Текущая чистая точка входа — nginx_rifter.py, инструмент с приоритетом оценки, предназначенный быть ближе к тому, как авторизованный тестер оценивал бы известную уязвимую установку nginx с доступным по HTTP примитивом чтения локальных файлов.

По сравнению с первоначальным демонстрационным раннером, nginx_rifter.py улучшает рабочий процесс в нескольких аспектах:

• Оценка выполняется по умолчанию. Инструмент не запускает крашащий эксплойт, если явно не указан --exploit.
• Цель задаётся как HOST:PORT, а примитив чтения файлов модульный через --file-read-template.
• Он профилирует LFI-примитив перед тем, как полагаться на него, включая текстовое чтение, бинарное чтение, чтение диапазонов, /proc/self/status, /proc/self/maps и достижимость procfs воркера с тем же UID.
• Он обнаруживает карты воркеров nginx, libc, system(), build ID, хэши бинарников, детали ОС и настройки proc-mem/core через удалённый примитив.
• Он пытается обнаружить конфигурацию nginx из командной строки мастер-процесса и распространённых путей конфигов, затем помечает уязвимые кандидаты маршрутов с rewrite + set.
• Он выводит матрицу жизнеспособности цепочки эксплойта, чтобы отсутствующие предпосылки были видны до любой попытки эксплойта.
• Режим эксплойта явный и интегрирован в nginx_rifter.py; метод по умолчанию — coreless proc-mem.

Текущий nginx_rifter.py самодостаточен. Он больше не импортирует и не вызывает внешние ранние версии демо-PoC или tools/proc_mem_coreless_exploit.py для оценки или эксплуатации.

Более старая реализация nginx_rifter.py с управлением через core сохранена как nginx_rifter_core_v2_1.py.

Более новый artifacts/nginx_rifter_v3_coreless_exploit_20260519.gif показывает объединённый путь эксплойта coreless v3 nginx_rifter.py. demo4.gif показывает поток оценки и явного эксплойта из более раннего универсального инструмента с управлением через core. Ранее показанный nginx-aslr-demo.gif остаётся исходной демонстрацией эксплойта с включённым ASLR.

Использование

Протестировано на Ubuntu 24.04.3 LTS.

Оригинальное воспроизведение в Docker с отключённым ASLR:

1. ./setup.sh — собрать контейнер.
2. docker compose -f env/docker-compose.yml up — запустить уязвимый сервер NGINX.
3. python3 poc.py --shell — получить шелл.

Для локального процесса воспроизведения в Docker см. LAB.md.

Легаси-цепочка на виртуальной машине с включённым ASLR и управлением через core:

./nginx_rifter_core_v2_1.py --target <target-host>:19321 --exploit --cmd id --fast

Инструмент v3 с приоритетом оценки:

./nginx_rifter.py --target <target-host>:19321

nginx_rifter.py — это текущая ориентированная на реальные условия точка входа для оценки и интегрированного PoC. Его режим по умолчанию не запускает крашащий путь эксплойта. Он профилирует HTTP-примитив чтения файлов, проверяет диапазонное и бинарное чтение, снимает отпечатки ОС/nginx/libc, обнаруживает воркеры nginx и карты, значимые для ASLR, проверяет читаемость /proc/<worker>/mem с тем же UID, пытается восстановить пути конфигурации nginx через чтение pid/cmdline/config, помечает уязвимые кандидаты маршрутов rewrite + set и выводит матрицу жизнеспособности текущей цепочки coreless.

Текущий nginx_rifter.py самодостаточен. Он больше не импортирует и не вызывает внешние ранние версии демо-PoC или автономный исследовательский стенд proc-mem для оценки или эксплуатации.

Для нестандартной формы LFI/download:

./nginx_rifter.py --target <target-host>:19321 \
  --file-read-template 'http://{host}:{port}/download?path={path_url}{range_query}'

Выполнение эксплойта явное:

./nginx_rifter.py --target <target-host>:19321 --exploit --cmd id --fast

# Смоук-тест эксплойта только для обнаружения, без распыления/зондирования
./nginx_rifter.py --target <target-host>:19321 --exploit --derive-only --cmd id

Метод эксплойта по умолчанию — coreless proc-mem. Следующие параметры уже выбраны по умолчанию, поскольку они были наиболее надёжными для coreless Docker-доказательства:

--exploit-method proc-mem
--target-len 6
--max-region 268435456

Легаси-режим с читаемым core всё ещё доступен для сравнения, но версионированный скрипт понятнее для воспроизведения того более старого пути:

./nginx_rifter_core_v2_1.py --target <target-host>:19321 --exploit --cmd id --fast

Легаси-демонстрация терминала, удобная для записи:

./demo_ctf_exploit_v1_9.py --host <target-host>:19321 --cmd id --clear

demo_ctf_exploit_v1_9.py — это более старый раннер для оператора лабораторного пути с управлением через core. Текущая предпочтительная точка входа PoC — nginx_rifter.py.

Примитив чтения файлов по умолчанию — PHP-маршрут этого форка:

/lfi.php?file=<path>&offset=<n>&length=<n>

Для другого известного уязвимого CTF-приложения или тестовой платформы вектор чтения файлов модульный:

./nginx_rifter.py --target <target-host>:19321 --exploit --cmd id \
  --target-profile generic \
  --file-read-template 'http://{host}:{port}/download?path={path_url}{range_query}'

Шаблон поддерживает {host}, {port}, {path_url}, {offset}, {length} и {range_query}. Профиль generic пропускает специфичные для лаборатории этого форка проверки конфигурации nginx, но эксплойт по умолчанию по-прежнему требует тех же базовых возможностей: читаемые карты /proc воркера nginx, читаемый libc и читаемый /proc/<worker>/mem. phpinfo() необязателен; используйте --phpinfo-path '', чтобы отключить его.

Оговорка о реалистичности: класс ошибок LFI/чтения файлов и модель развёртывания nginx/PHP-FPM на одном хосте реалистичны. Цепочка proc-mem реалистичнее более ранней цепочки crash-core, поскольку не требует включения или чтения core dump воркеров. Она всё ещё не является универсальным предположением для продакшена: компоновка процессов с одинаковым UID, политика procfs/Yama, настройки пространств имён контейнера и качество примитива чтения файлов определяют, доступен ли /proc/<worker>/mem.

Исследовательские зонды без LFI:

python3 tools/non_lfi_leak_probe.py --target <target-host>:19321
python3 tools/non_lfi_active_response_probe.py --target <target-host>:19321

Это негативные исследовательские зонды, а не точки входа эксплойта. Они проверяют пассивные отражённые стоки и начальную форму over-read с отложенным ответом без использования LFI, phpinfo, procfs, core, доступа отладчика или жёстко заданных живых баз ASLR.

Дополнительные лабораторные заметки и журналы запусков находятся в docs/, особенно:

• docs/CTF_PLAN.md
• docs/CTF_FINDINGS.md
• docs/CTF_TESTS.md
• docs/CTF_EXPERIMENT_LOG.md
• docs/DEMO_POC_IMPROVEMENTS.md
• docs/KNOWN_LAYOUT_PATTERNS.md
• docs/VAGRANT_ESXI.md
• docs/CORELESS_ASLR_PLAN.md
• docs/CORELESS_ASLR_FINDINGS.md
• docs/NON_LFI_ASLR_BYPASS_LOG.md
• docs/DEMO_RECORDING_WORKFLOW.md