Chronomaly

Chronomaly — это эксплойт ядра для Android/Linux, использующий CVE-2025-38352. Эксплойт был написан специально для ядра Linux v5.10.157, но должен работать против всех уязвимых ядер v5.10.x, так как для его работы не требуется каких-либо конкретных смещений текста ядра.

Я подробно описал уязвимость в серии из трёх постов в блоге, от PoC до эксплойта:

• Часть 1 — Анализ уязвимости ядра Android «в дикой природе» + PoC
• Часть 2 — Расширение окна гонки без патча ядра
• Часть 3 — Раскрытие Chronomaly

Настройка сборки

Этот эксплойт тестировался только на ядре Linux x86_64 v5.10.157, запущенном в QEMU. Я попросил друга прислать мне конфиг ядра Pixel 6a, чтобы использовать его как основу для своего конфига, и вот какие параметры конфигурации важны для этого эксплойта (за основу я взял конфиг kernelCTF):

• CONFIG_POSIX_CPU_TIMERS_TASK_WORK=n
• CONFIG_PREEMPT=y (Полное вытеснение, без RT)
• CONFIG_SLAB_MERGE_DEFAULT=n
• DEBUG_LIST=n
• BUG_ON_DATA_CORRUPTION=n
• LIST_HARDENED=n

Чтобы отключить CONFIG_POSIX_CPU_TIMERS_TASK_WORK, вы можете следовать шагам, описанным в моём первом посте в блоге здесь.

Обратитесь к файлу qemu.sh за моим скриптом запуска QEMU. Для тестирования я использовал 4 ядра и 3 ГБ ОЗУ.

Параметры эксплойта, которые вам нужно изменить

Поскольку эксплойт зависит от таймеров ЦП, возможно, потребуется изменить два параметра для адаптации к вашему окружению.

CPU_USAGE_THRESHOLD

Этот параметр используется при потреблении времени ЦП для срабатывания таймеров внутри race_func(). Он должен быть установлен так, чтобы:

• Таймеры не срабатывали при каждой попытке повторения (это означало бы, что CPU_USAGE_THRESHOLD слишком высок — таймеры срабатывают до того, как поток race_func() успеет завершиться).
• Таймеры срабатывали лишь иногда (это означало бы, что иногда таймеры срабатывают до завершения потока, а иногда — одновременно с его завершением).

Чтобы определить, срабатывают ли таймеры, вставьте оператор printf() в код опроса SIGUSR1 в функции free_func(). Если вы увидите сообщение на экране, значит, таймеры сработали.

При правильной настройке вы начнёте видеть сообщения «Parent raced too late / too early» в терминале.

PARENT_SETTIME_DELAY_US

PARENT_SETTIME_DELAY_US. Этот параметр используется родительским процессом для попадания во второе окно гонки внутри send_sigqueue() одновременно с дочерним процессом. Запустите эксплойт, наблюдайте и изменяйте параметр следующим образом:

• Сообщение «Parent raced too late, readjusting...» появляется слишком часто — уменьшите этот параметр.
• Сообщение «Parent raced too early, readjusting...» появляется слишком часто — увеличьте этот параметр.

В идеале вы должны видеть на экране как «raced too late», так и «raced too early» — тогда эксплойт сработает в течение 1 минуты. Если вы видите, что одно сообщение появляется чаще другого, отрегулируйте параметр соответствующим образом.

Возможные улучшения

В своей реализации кросс-кэша я исходил из предположения, что ядро не слишком загружено и что аллокаций struct sigqueue было немного. Я добавил комментарий в sigqueue_crosscache_preallocs(), где объясняется, что нужно сделать для улучшения.

Если ядро сильно загружено или на списке частичных страниц (per-cpu / per-node) уже есть несколько slab-страниц struct sigqueue, то текущая реализация кросс-кэша в exploit.c не сработает, и uaf_sigqueue / realloc_sigqueue не будут перераспределены как страница данных буфера канала.

Я намеренно не стал делать кросс-кэш рабочим в загруженном ядре, чтобы эксплойтом не злоупотребляли :)

Вопросы

Если у вас есть вопросы, пожалуйста, свяжитесь со мной через X / Twitter!