Chronomaly

Chronomaly è un exploit per il kernel Android/Linux che sfrutta CVE-2025-38352. L'exploit è stato scritto specificamente per il kernel Linux v5.10.157, ma dovrebbe funzionare contro tutti i kernel v5.10.x vulnerabili, poiché non richiede offset specifici del testo del kernel per funzionare.

Ho trattato la vulnerabilità in dettaglio in una serie di tre articoli sul blog, dal PoC all'exploit:

• Parte 1 - Analisi della vulnerabilità del kernel Android in-the-wild + PoC
• Parte 2 - Estendere la finestra di race condition senza una patch del kernel
• Parte 3 - Alla scoperta di Chronomaly

Configurazione di compilazione

Questo exploit è stato testato solo su un kernel Linux x86_64 v5.10.157 in esecuzione su QEMU. Ho chiesto a un amico di inviarmi la configurazione del kernel del suo Pixel 6a per basare la mia configurazione del kernel, e queste sono le opzioni di configurazione importanti per questo exploit (ho iniziato dalla configurazione kernelCTF come base):

• CONFIG_POSIX_CPU_TIMERS_TASK_WORK=n
• CONFIG_PREEMPT=y (Full Preemption, no RT)
• CONFIG_SLAB_MERGE_DEFAULT=n
• DEBUG_LIST=n
• BUG_ON_DATA_CORRUPTION=n
• LIST_HARDENED=n

Per disabilitare CONFIG_POSIX_CPU_TIMERS_TASK_WORK, puoi seguire i passaggi descritti nel mio primo articolo del blog qui.

Fai riferimento al file qemu.sh per il mio script di esecuzione QEMU. Ho usato 4 core e 3 GB di RAM per i test.

Parametri dell'exploit che dovrai modificare

Poiché l'exploit dipende dai timer della CPU, ci sono due parametri che potresti dover modificare per adattarlo al tuo ambiente.

CPU_USAGE_THRESHOLD

Questo parametro viene utilizzato quando si consuma tempo CPU per attivare i timer all'interno di race_func(). Deve essere impostato in modo tale che:

• I timer non scattino ad ogni tentativo (questo implicherebbe che CPU_USAGE_THRESHOLD è troppo alto, poiché i timer scattano prima che il thread race_func() possa uscire).
• I timer scattino solo a volte (questo implicherebbe che a volte i timer scattano prima che il thread esca, e altre volte scattano mentre il thread esce).

Per determinare se i timer stanno scattando o meno, inserisci una dichiarazione printf() nel codice di polling di SIGUSR1 in free_func(). Se vedi il messaggio stampato, significa che i timer sono scattati.

Se impostato correttamente, inizierai a vedere i messaggi "Parent raced too late / too early" nel terminale.

PARENT_SETTIME_DELAY_US

PARENT_SETTIME_DELAY_US. Questo parametro viene utilizzato dal processo padre per colpire la seconda finestra di race condition all'interno di send_sigqueue() contemporaneamente al processo figlio. Esegui l'exploit, osserva e modificalo come segue:

• Il messaggio "Parent raced too late, readjusting..." appare troppo spesso – riduci questo parametro.
• Il messaggio "Parent raced too early, readjusting..." appare troppo spesso – aumenta questo parametro.

Idealmente, vuoi vedere entrambi i messaggi "raced too late" e "raced too early" stampati e l'exploit funzionerà entro 1 minuto. Se ne vedi solo uno che si verifica più dell'altro, regola di conseguenza.

Miglioramenti potenziali

Nella mia implementazione cross-cache, ho assunto che il kernel non sia troppo occupato e che non ci siano state molte allocazioni di struct sigqueue. Ho aggiunto un commento in sigqueue_crosscache_preallocs() che spiega cosa dovresti fare per migliorare questo aspetto.

Se il kernel è molto occupato, o se ci sono già alcune pagine slab di struct sigqueue nella lista parziale per-CPU o per-nodo, allora l'attuale implementazione cross-cache in exploit.c fallirà, e uaf_sigqueue / realloc_sigqueue non verranno riallocate come pagina dati del buffer della pipe.

Ho scelto deliberatamente di non far funzionare il cross-cache in un kernel occupato, in modo che l'exploit non venga abusato :)

Domande

Se hai domande, contattami su X / Twitter!