Chronomaly

Chronomaly est une exploitation du noyau pour le noyau Android / Linux utilisant CVE-2025-38352. L'exploit a été écrit spécifiquement pour le noyau Linux v5.10.157, mais devrait fonctionner contre tous les noyaux vulnérables v5.10.x, car il ne nécessite aucun décalage de texte spécifique du noyau pour fonctionner.

J'ai couvert la vulnérabilité en détail dans une série d'articles en trois parties, du PoC à l'exploit :

• Partie 1 - Analyse d'une vulnérabilité du noyau Android exploitée dans la nature + PoC
• Partie 2 - Élargir la fenêtre de course sans correctif du noyau
• Partie 3 - À la découverte de Chronomaly

Configuration de compilation

Cet exploit n'a été testé que contre un noyau Linux x86_64 v5.10.157 tournant dans QEMU. J'ai demandé à un ami de m'envoyer la configuration du noyau de son Pixel 6a pour baser ma configuration de noyau dessus, et voici les options de configuration importantes pour cet exploit (je suis parti de la configuration kernelCTF comme base) :

• CONFIG_POSIX_CPU_TIMERS_TASK_WORK=n
• CONFIG_PREEMPT=y (Préemption complète, pas de RT)
• CONFIG_SLAB_MERGE_DEFAULT=n
• DEBUG_LIST=n
• BUG_ON_DATA_CORRUPTION=n
• LIST_HARDENED=n

Pour désactiver CONFIG_POSIX_CPU_TIMERS_TASK_WORK, vous pouvez suivre les étapes décrites dans mon premier article de blog ici.

Référez-vous au fichier qemu.sh pour mon script d'exécution QEMU. J'ai utilisé 4 cœurs et 3 Go de RAM pour les tests.

Paramètres de l'exploit que vous devrez modifier

Étant donné que l'exploit dépend des minuteries CPU, il y a deux paramètres que vous devrez peut-être modifier pour l'adapter à votre environnement.

CPU_USAGE_THRESHOLD

Ce paramètre est utilisé lors de la consommation du temps CPU pour déclencher les minuteries à l'intérieur de race_func(). Il doit être défini de telle sorte que :

• Les minuteries ne se déclenchent pas à chaque tentative (cela impliquerait que CPU_USAGE_THRESHOLD est trop élevé, car les minuteries se déclenchent avant que le thread race_func() ne puisse se terminer).
• Les minuteries ne se déclenchent que parfois (cela impliquerait que parfois les minuteries se déclenchent avant la fin du thread, et d'autres fois elles se déclenchent pendant la fin du thread).

Pour déterminer si les minuteries se déclenchent ou non, insérez une instruction printf() dans le code d'interrogation SIGUSR1 de free_func(). Si vous voyez le message s'afficher, cela signifie que les minuteries se sont déclenchées.

Si le réglage est correct, vous commencerez à voir les messages « Parent raced too late / too early » dans le terminal.

PARENT_SETTIME_DELAY_US

PARENT_SETTIME_DELAY_US. Ce paramètre est utilisé par le processus parent pour atteindre la 2ème fenêtre de course dans send_sigqueue() en même temps que le processus enfant. Exécutez l'exploit, observez, et modifiez-le comme suit :

• Le message « Parent raced too late, readjusting... » apparaît trop souvent – réduisez ce paramètre.
• Le message « Parent raced too early, readjusting... » apparaît trop souvent – augmentez ce paramètre.

Idéalement, vous voulez voir à la fois « raced too late » et « raced too early » être affichés, et l'exploit fonctionnera en moins d'une minute. Si vous voyez qu'un seul apparaît plus que l'autre, ajustez en conséquence.

Améliorations possibles

Dans mon implémentation de cross-cache, j'ai supposé que le noyau n'est pas trop occupé et qu'il n'y a pas eu beaucoup d'allocations de struct sigqueue. J'ai ajouté un commentaire dans sigqueue_crosscache_preallocs() qui explique ce que vous devriez faire pour améliorer cela.

Si le noyau est vraiment occupé, ou s'il y a déjà des pages slab struct sigqueue sur la liste partielle par CPU / par nœud, alors l'implémentation actuelle du cross-cache dans exploit.c échouera, et uaf_sigqueue / realloc_sigqueue ne seront pas réalloués en tant que page de données de pipe buffer.

J'ai délibérément choisi de ne pas faire fonctionner le cross-cache dans un noyau occupé, afin que l'exploit ne soit pas utilisé à mauvais escient :)

Questions

Si vous avez des questions, contactez-moi via X / Twitter !