Chronomaly

Chronomaly ist ein Kernel-Exploit für den Android- / Linux-Kernel unter Verwendung von CVE-2025-38352. Der Exploit wurde speziell für den Linux-Kernel v5.10.157 geschrieben, sollte aber gegen alle anfälligen v5.10.x-Kernel funktionieren, da er keine spezifischen Kernel-Text-Offsets benötigt.

Ich habe die Sicherheitslücke in einer dreiteiligen Blogbeitragsreihe detailliert behandelt, vom PoC bis zum Exploit:

• Teil 1 – Analyse einer im Feld gefundenen Android-Kernel-Sicherheitslücke + PoC
• Teil 2 – Erweiterung des Race-Fensters ohne Kernel-Patch
• Teil 3 – Aufdeckung von Chronomaly

Build-Einrichtung

Dieser Exploit wurde nur gegen einen x86_64-Linux-Kernel v5.10.157 getestet, der in QEMU läuft. Ich habe einen Freund gebeten, mir seine Pixel 6a-Kernel-Konfiguration zu schicken, um meine Kernel-Konfiguration darauf zu basieren, und dies sind die für diesen Exploit wichtigen Konfigurationsoptionen (ich habe die kernelCTF-Konfiguration als Basis verwendet):

• CONFIG_POSIX_CPU_TIMERS_TASK_WORK=n
• CONFIG_PREEMPT=y
• CONFIG_SLAB_MERGE_DEFAULT=n
• DEBUG_LIST=n
• BUG_ON_DATA_CORRUPTION=n
• LIST_HARDENED=n

Um CONFIG_POSIX_CPU_TIMERS_TASK_WORK zu deaktivieren, können Sie den Schritten in meinem ersten Blogbeitrag hier folgen.

Siehe die Datei qemu.sh für mein QEMU-Ausführungsskript. Ich habe 4 Kerne und 3 GB RAM zum Testen verwendet.

Exploit-Parameter, die Sie anpassen müssen

Da der Exploit von CPU-Timern abhängt, gibt es zwei Parameter, die Sie möglicherweise anpassen müssen, um ihn an Ihre Umgebung anzupassen.

CPU_USAGE_THRESHOLD

Dieser Parameter wird verwendet, wenn CPU-Zeit verbraucht wird, um die Timer innerhalb von race_func() auszulösen. Er muss so eingestellt sein, dass:

• Die Timer nicht bei jedem erneuten Versuch ausgelöst werden (das würde bedeuten, dass CPU_USAGE_THRESHOLD zu hoch ist, da die Timer ausgelöst werden, bevor der race_func()-Thread beendet werden kann).
• Die Timer werden nur manchmal ausgelöst (das würde bedeuten, dass die Timer manchmal ausgelöst werden, bevor der Thread beendet wird, und manchmal während der Thread beendet wird).

Um festzustellen, ob die Timer ausgelöst werden oder nicht, fügen Sie eine printf()-Anweisung im SIGUSR1-Polling-Code in free_func() ein. Wenn Sie die Nachricht auf der Konsole sehen, bedeutet das, dass die Timer ausgelöst wurden.

Bei korrekter Einstellung werden Sie die Meldungen "Parent raced too late / too early" im Terminal sehen.

PARENT_SETTIME_DELAY_US

PARENT_SETTIME_DELAY_US. Dieser Parameter wird vom Elternprozess verwendet, um das zweite Race-Fenster innerhalb von send_sigqueue() gleichzeitig mit dem Kindprozess zu treffen. Führen Sie den Exploit aus, beobachten Sie und passen Sie ihn wie folgt an:

• Die Meldung "Parent raced too late, readjusting..." erscheint zu oft – reduzieren Sie diesen Parameter.
• Die Meldung "Parent raced too early, readjusting..." erscheint zu oft – erhöhen Sie diesen Parameter.

Idealerweise möchten Sie, dass sowohl "raced too late" als auch "raced too early" ausgegeben werden, und der Exploit wird innerhalb von 1 Minute funktionieren. Wenn Sie nur feststellen, dass eines häufiger als das andere auftritt, passen Sie entsprechend an.

Mögliche Verbesserungen

In meiner Cross-Cache-Implementierung habe ich angenommen, dass der Kernel nicht zu ausgelastet ist und dass es nicht viele struct sigqueue-Allokationen gegeben hat. Ich habe einen Kommentar in sigqueue_crosscache_preallocs() hinzugefügt, der erklärt, was Sie tun müssten, um dies zu verbessern.

Wenn der Kernel wirklich ausgelastet ist oder bereits einige struct sigqueue-Slab-Seiten auf der Pro-CPU/Pro-Node-Partial-Liste vorhanden sind, wird die aktuelle Cross-Cache-Implementierung in exploit.c fehlschlagen, und die uaf_sigqueue/realloc_sigqueue werden nicht als Pipe-Buffer-Datenseite neu allokiert.

Ich habe bewusst darauf verzichtet, das Cross-Cache in einem ausgelasteten Kernel funktionieren zu lassen, damit der Exploit nicht missbraucht wird :)

Fragen

Bei Fragen kontaktieren Sie mich bitte über X / Twitter!