Linux arm64 Static Linear Map KASLR Bypass

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Übersicht

Android-Kernel, die für arm64 gebaut sind, aktivieren nahezu universell CONFIG_ARM64_VA_BITS=39 (3-stufiges Paging) und CONFIG_MEMORY_HOTPLUG=y. Mit nur 512 GiB verfügbarem Kernel-Virtualspace haben die Linux-Entwickler beschlossen, die linear map am niedrigstmöglichen Kernel-VA zu verankern, damit zukünftig hinzugefügter Hot-Plug-RAM die Abbildung einfach nach oben erweitern kann. Seit dem Commit 1db780bafa4c versucht arm64 nicht einmal mehr, diese Platzierung zu randomisieren, was bedeutet:

  • PAGE_OFFSET = 0xffffff8000000000 ist fest kompiliert.
  • PHYS_OFFSET wird aus der exportierten memstart_addr bezogen, die auf Stock-Android-Geräten effektiv konstant ist (heute 0x80000000).

Infolgedessen hat jede physische Seite eine deterministische linear-map virtuelle Adresse, die unabhängig vom KASLR slide ist:

#define phys_to_virt(p) (((unsigned long)(p) - 0x80000000UL) | 0xffffff8000000000UL)

Wenn ein Angreifer eine physische Adresse (kernel object, PFN aus /proc/pagemap oder sogar eine vom Benutzer kontrollierte page) erlernen oder beeinflussen kann, kennt er sofort die entsprechende kernel virtual address, without leaking the randomized primary kernel mapping.

Lesen von memstart_addr und Bestätigung der Transformation

memstart_addr wird in /proc/kallsyms exportiert und kann auf rooted devices oder über ein beliebiges kernel-read primitive gelesen werden. Project Zero verwendete Jann Horns tracing-BPF-Helfer (bpf_arb_read), um es direkt zu dumpen:

grep memstart /proc/kallsyms
# ... obtains memstart_addr virtual address
./bpf_arb_read <addr_of_memstart_addr> 8

Die Bytes 00 00 00 80 00 00 00 00 bestätigen memstart_addr = 0x80000000. Sobald PAGE_OFFSET und PHYS_OFFSET festliegen, ist die arm64 linear map eine statische affine Abbildung jeder physischen Adresse.

Ermittlung stabiler .data-Adressen auf Geräten mit festem kernel physbase

Viele Pixel-Geräte entpacken den Kernel bei jedem Boot noch an phys_kernel_base = 0x80010000 (sichtbar in /proc/iomem). In Kombination mit der statischen Abbildung ergeben sich dadurch reboot-stabile Adressen für beliebige Daten-Symbole:

  1. Notiere die randomisierte kernel-virtuelle Adresse von _stext und deines Zielsymbols aus /proc/kallsyms (oder aus dem exakten vmlinux).
  2. Berechne den Offset: offset = sym_virt - _stext_virt.
  3. Addiere die statische Boot-Physbase: phys_sym = 0x80010000 + offset.
  4. Wandle in eine linear-map-VA um: virt_sym = phys_to_virt(phys_sym).

Beispiel (modprobe_path auf einem Pixel 9): offset = 0x1fe2398, phys = 0x81ff2398, virt = 0xffffff8001ff2398. Nach mehreren Neustarts liefert bpf_arb_read 0xffffff8001ff2398 dieselben Bytes zurück, sodass Exploit-Payloads 0xffffff8000010000 als synthetische, nicht-randomisierte Basis für alle .data-Offsets behandeln können.

Diese Abbildung ist RW, daher kann jedes Primitive, das Angreiferdaten in den kernel-virtuellen Raum platzieren kann (double free, UAF, non-paged heap write, etc.), Credentials, LSM-Hooks oder Dispatch-Tabellen patchen, ohne jemals die echte KASLR slide zu leak-en. Die einzige Einschränkung ist, dass .text im linear map als nicht ausführbar gemappt ist, sodass gadget hunting weiterhin einen traditionellen leak erfordert.

PFN spraying, wenn der kernel physbase randomisiert ist

Vendors wie Samsung randomisieren die Kernel-Load-PFN, aber die statische linear map ist weiterhin missbrauchbar, weil die PFN-Allokation nicht vollständig zufällig ist:

  1. Spray user pages: mmap() ~5 GiB, touch every page to fault it in.
  2. Harvest PFNs: lese /proc/pagemap für jede Seite (oder verwende einen anderen PFN leak), um die Backing-PFN-Liste zu sammeln.
  3. Repeat and profile: Neustart, 100× erneut ausführen, ein Histogramm erstellen, das zeigt, wie oft jeder PFN vom Angreifer kontrolliert wurde. Manche PFNs sind sehr heiß (100/100 Mal kurz nach dem Boot zugewiesen).
  4. Convert PFN → kernel VA:
  • phys = (pfn << PAGE_SHIFT) + offset_in_page
  • virt = phys_to_virt(phys)
  1. Forge kernel objects in those pages und lenke Victim-Pointer (UAF, overflow, etc.) auf die bekannten linear-map-Adressen.

Da die linear map identitätsgemappten RW-Speicher darstellt, erlaubt diese Technik, vollständig vom Angreifer kontrollierte Daten an deterministischen Kernel-VAs zu platzieren, selbst wenn die echte Kernel-Basis verschoben ist. Exploits können gefälschte file_operations, cred oder refcount-Strukturen in den gesprayten Seiten vorab aufbauen und dann existierende Kernel-Pointer darauf umleiten.

Praktischer Workflow für arm64 Android Exploits

  1. Informationsbeschaffung
  • Root oder benutze ein kernel read primitive, um memstart_addr, _stext und das Zielsymbol aus /proc/kallsyms zu dumpen.
  • Auf Pixels kann man der statischen physbase aus /proc/iomem vertrauen; auf anderen Geräten PFN-Profiler vorbereiten.
  1. Adressberechnung
  • Wende die oben beschriebene Offset-Mathematik an und cache die resultierenden linear-map-VAs in deinem Exploit.
  • Für PFN spraying behalte eine Liste “reliabler” PFNs, die wiederholt im Angreifer-Speicher landen.
  1. Exploit-Integration
  • Wenn ein arbitrary write verfügbar ist, patche direkt Ziele wie modprobe_path, init_cred oder security ops arrays an den vorberechneten Adressen.
  • Wenn nur eine Heap-Korruption existiert, erstelle gefälschte Objekte in den bekannten überwachten Seiten und zeige Victim-Pointer auf diese linear-map-VAs um.
  1. Verifikation
  • Verwende bpf_arb_read oder ein anderes sicheres Read-Primitive, um vor destruktiven Writes zu prüfen, dass die berechnete Adresse die erwarteten Bytes enthält.

Dieser Workflow eliminiert die KASLR-leak-Phase bei datenorientierten Kernel-Exploits auf Android, was die Exploit-Komplexität drastisch reduziert und die Zuverlässigkeit verbessert.

References

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks