Chronomaly

Chronomaly es un exploit del kernel para el kernel de Android / Linux usando CVE-2025-38352. El exploit fue escrito específicamente para el kernel de Linux v5.10.157, pero debería funcionar contra todos los kernels vulnerables v5.10.x, ya que no requiere ningún offset específico del texto del kernel para funcionar.

Cubrí la vulnerabilidad en detalle en una serie de publicaciones de blog de tres partes, desde el PoC hasta el exploit:

• Parte 1 - Análisis de Vulnerabilidad del Kernel Android en estado salvaje + PoC
• Parte 2 - Extendiendo la Ventana de Carrera Sin un Parche del Kernel
• Parte 3 - Descubriendo Chronomaly

Configuración de Compilación

Este exploit solo se ha probado contra un kernel de Linux x86_64 v5.10.157 ejecutándose en QEMU. Le pedí a un amigo que me enviara su configuración de kernel del Pixel 6a para basar mi configuración de kernel, y estas son las opciones de configuración importantes para este exploit (empecé desde la configuración de kernelCTF como base):

• CONFIG_POSIX_CPU_TIMERS_TASK_WORK=n
• CONFIG_PREEMPT=y (Preemption Completa, sin RT)
• CONFIG_SLAB_MERGE_DEFAULT=n
• DEBUG_LIST=n
• BUG_ON_DATA_CORRUPTION=n
• LIST_HARDENED=n

Para deshabilitar CONFIG_POSIX_CPU_TIMERS_TASK_WORK, puedes seguir los pasos descritos en mi primera publicación del blog aquí.

Consulte el archivo qemu.sh para mi script de ejecución de QEMU. Usé 4 núcleos y 3 GB de RAM para las pruebas.

Parámetros del exploit que necesitarás cambiar

Dado que el exploit depende de temporizadores de la CPU, hay dos parámetros que quizás necesites cambiar para adaptarlo a tu entorno.

CPU_USAGE_THRESHOLD

Este parámetro se usa al consumir tiempo de CPU para disparar los temporizadores dentro de race_func(). Debe configurarse de manera que:

• Los temporizadores no se disparen en cada intento de reintento (esto implicaría que CPU_USAGE_THRESHOLD es demasiado alto, ya que los temporizadores se disparan antes de que el hilo race_func() pueda salir).
• Los temporizadores solo se disparen a veces (esto implicaría que a veces los temporizadores se disparan antes de que el hilo salga, y otras veces se disparan mientras el hilo sale).

Para determinar si los temporizadores se están disparando o no, inserta una declaración printf() en el código de sondeo de SIGUSR1 en free_func(). Si ves el mensaje impreso, significa que los temporizadores se dispararon.

Si se configura correctamente, comenzarás a ver los mensajes "Parent raced too late / too early" en la terminal.

PARENT_SETTIME_DELAY_US

PARENT_SETTIME_DELAY_US. Este parámetro es usado por el proceso padre para alcanzar la segunda ventana de carrera dentro de send_sigqueue() al mismo tiempo que el proceso hijo. Ejecuta el exploit, observa y modifícalo de la siguiente manera:

• El mensaje "Parent raced too late, readjusting..." aparece con demasiada frecuencia – reduce este parámetro.
• El mensaje "Parent raced too early, readjusting..." aparece con demasiada frecuencia – aumenta este parámetro.

Idealmente, querrás ver que tanto "raced too late" como "raced too early" se impriman, y el exploit funcionará en menos de 1 minuto. Si solo ves que uno ocurre más que el otro, ajusta en consecuencia.

Mejoras Potenciales

En mi implementación de cross-cache, asumí que el kernel no está demasiado ocupado y que no ha habido muchas asignaciones de struct sigqueue. Agregué un comentario en sigqueue_crosscache_preallocs() que explica lo que necesitarías hacer para mejorar esto.

Si el kernel está realmente ocupado, o ya hay algunas páginas slab de struct sigqueue en la lista parcial por CPU / por nodo, entonces la implementación actual de cross-cache en exploit.c fallará, y uaf_sigqueue / realloc_sigqueue no se reasignarán como una página de datos de búfer de pipe.

Elegí deliberadamente no hacer que el cross-cache funcione en un kernel ocupado, para que el exploit no sea mal utilizado :)

Preguntas

Si tienes alguna pregunta, ¡contáctame a través de X / Twitter!