|
Professor Seleznov
|
Свежая CVE-2026-31431 только набирает обороты, и тут я хочу показать, почему это не совсем обычная LPE.
Copy Fail как примитив Process Injection через Page Cache
Оригинальный PoC модифицирует setuid binary перед execve и получает root.
Второй публичный PoC подменяет id у текущего юзера на 0000.
Хорошие, рабочие LPE, дающие рута.
Но исследуя дополнительные свойства этого примитива я обнаружил несколько эффектов, не описанных в оригинальном disclosure:
- Copy Fail позволяет модифицировать код уже запущенного процесса — без ptrace и без взаимодействия с процессом. Без execve для запуска кода.
- Модификация невидима для inotify, не обновляет mtime файла, невидима для auditd и других стандартных инструментов отслеживания инжекта в процесс.
- Модифицировать можно не только 4 байта, в цикле примитивами был модифицирован файл в 100 Кб данных за 6.5 секунд.
Live Code Injection в работающий процесс
Исполняемый файл загружается через mmap(file, MAP_PRIVATE, PROT_READ|PROT_EXEC).
.text segment доступен только на чтение — процесс в него не пишет, COW не происходит. PTE указывает на page cache page файла.
Copy Fail модифицирует эту page cache page через crypto subsystem (AF_ALG + splice + authencesn scratch write). Процесс видит изменённый код при следующем исполнении инструкции с модифицированной page.
Аналогичный механизм использовал Dirty Pipe (CVE-2022-0847) — запись в page cache через splice. Разница: Dirty Pipe модифицировал pipe buffer flags, Copy Fail использует scratch write в authencesn. Класс атаки один — эксплуатация разделяемости page cache между файловым кэшем и memory mappings процессов.
Max Kellerman ещё в 2022, раскрывая Dirty Pipe, отметил что page cache write позволяет «inject code into arbitrary processes».
На Copy.Fail это сработало на практике, и заодно обнаружилось, что стандартный Linux detection stack не очень готов к этому.
PoC
Модификация инструкции в работающем процессе:
// test_loop.c
// gcc -o /tmp/test_loop /tmp/test_loop.c
int check() { return 42; }
int main()
{
while(1) {
printf(“check() = %d\n”, check());
sleep(2);
}
}
$ objdump -d /tmp/test_loop | grep -A1 ""
114d: b8 2a 00 00 00 mov $0x2a,%eax ← return 42
Перезаписываем mov $0x2a → mov $0x539 (offset 0x114d = 4429 decimal):
$ python3 copy_fail_write.py/tmp/test_loop 4429 b8390500
Результат на работающем процессе:
check() = 42
check() = 42
check() = 1337 ← код изменён без остановки процесса
check() = 1337
Протестировано на Debian 6.1.0-25,x86_64 и aarch64
Процесс не останавливался, ptrace не использовался, /proc/PID/mem не открывался.
На уязвимых системах это рабочий способ инжекта в процесс в Linux.
Detection stack для process injection не покрывает этот случай.
Синие должны мониторить AF_ALG, не только ptrace.
Незаметный и необнаруживаемый, что немного усложняет и без того эпичный баг.
Какие механизмы защиты это обходит
Все задокументированные подходы (MITRE DET0203, DET0508, Tracee TRC-1024, Akamai guide) мониторят ptrace, /proc/PID/mem, process_vm_writev.
Page cache injection не использует ни один из этих механизмов — атакующий процесс работает только с файлом (AF_ALG socket + splice).
Теперь ловить нужно и AF_ALG сокет.
YAMA ptrace_scope — ограничивает ptrace. Не применимо, ptrace не используется.
Seccomp — зависит от профиля.
Docker default и Kubernetes PSS Restricted не блокируют AF_ALG (подтверждено Juliet Security). Профиль, явно блокирующий socket(AF_ALG, …), предотвращает атаку.
auditd ptrace/procfs rules — не срабатывают (ptrace и /proc/PID/mem не используются). Невидимость для файлового мониторинга
Copy Fail не вызывает write() на целевом файле.
Модификация page cache происходит внутри crypto subsystem через scatterwalk_map_and_copy(). inotify — не видит модификацию
$ inotifywait -m /tmp/copyfail_test.txt &
$ python3 copy_fail_write.py /tmp/copyfail_test.txt 0 --text "PWND"
/tmp/copyfail_test.txt OPEN
/tmp/copyfail_test.txt ACCESS
/tmp/copyfail_test.txt CLOSE_NOWRITE,CLOSE
Событие MODIFY не генерируется.
Зафиксированы только OPEN, ACCESS, CLOSE_NOWRITE — нормальные события чтения. Инструменты, зависящие от inotify (systemd path units, часть EDR), не получают уведомления об изменении. mtime/ctime — не обновляются
Modify: 2026-05-01 00:13:34 # до Copy Fail
Modify: 2026-05-01 00:13:34 # после — без изменений
Обратимость
Модификация page cache обратима через posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED) — ядро сбрасывает страницы из кэша, следующее чтение загружает оригинальные данные с диска.
Это делается без привилегий.
После сброса: содержимое файла восстановлено, хэши совпадают с baseline, mtime не менялся, inotify не срабатывал.
Полный цикл (inject → use → erase) похоже не особо видим для средств мониторинга.
Telegram: @secinfosex-Источник
|
