Linux arm64 Static Linear Map KASLR Bypass

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

Panoramica

I kernel Android compilati per arm64 abilitano quasi universalmente CONFIG_ARM64_VA_BITS=39 (paging a 3 livelli) e CONFIG_MEMORY_HOTPLUG=y. Avendo a disposizione solo 512 GiB di spazio virtuale del kernel, gli sviluppatori di Linux hanno scelto di ancorare la linear map al più basso kernel VA possibile in modo che la RAM aggiunta in seguito possa semplicemente estendere la mappatura verso l’alto. Dal commit 1db780bafa4c, arm64 non tenta nemmeno più di randomizzare quella posizione, il che significa:

  • PAGE_OFFSET = 0xffffff8000000000 è compilato.
  • PHYS_OFFSET proviene dall’esportato memstart_addr, che sui dispositivi Android stock è effettivamente costante (0x80000000 al momento).

Di conseguenza, ogni pagina fisica ha un indirizzo virtuale della linear-map deterministico che è indipendente dal KASLR slide:

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

Se un attacker può apprendere o influenzare un indirizzo fisico (oggetto del kernel, PFN da /proc/pagemap, o anche una pagina controllata dall’utente), conosce istantaneamente il corrispondente indirizzo virtuale del kernel senza dover rivelare la mappatura primaria del kernel randomizzata.

Lettura di memstart_addr e conferma della trasformazione

memstart_addr è esportato in /proc/kallsyms e può essere letto su dispositivi con root o tramite qualsiasi primitiva di lettura del kernel arbitraria. Project Zero ha utilizzato il tracing-BPF helper di Jann Horn (bpf_arb_read) per eseguirne il dump direttamente:

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

I byte 00 00 00 80 00 00 00 00 confermano memstart_addr = 0x80000000. Una volta che PAGE_OFFSET e PHYS_OFFSET sono fissati, la arm64 linear map è una trasformazione affine statica di qualsiasi indirizzo fisico.

Deriving stable .data addresses on devices with a fixed kernel physbase

Molti Pixel ancora decompattano il kernel a phys_kernel_base = 0x80010000 ad ogni avvio (visibile in /proc/iomem). Combinando questo con la trasformazione statica si ottengono indirizzi stabili fra i reboot per qualsiasi simbolo dati:

  1. Registra l’indirizzo virtuale del kernel randomizzato di _stext e del simbolo target da /proc/kallsyms (o dall’esatto vmlinux).
  2. Calcola l’offset: offset = sym_virt - _stext_virt.
  3. Aggiungi la physbase statica al boot: phys_sym = 0x80010000 + offset.
  4. Converti in un VA della linear-map: virt_sym = phys_to_virt(phys_sym).

Esempio (modprobe_path on a Pixel 9): offset = 0x1fe2398, phys = 0x81ff2398, virt = 0xffffff8001ff2398. Dopo molteplici reboot, bpf_arb_read 0xffffff8001ff2398 restituisce gli stessi byte, quindi exploit payloads possono trattare 0xffffff8000010000 come una base sintetica non randomizzata per tutti gli offset .data.

Questa mappatura è RW, quindi qualsiasi primitive che possa collocare dati dell’attacker nello spazio virtuale del kernel (double free, UAF, non-paged heap write, ecc.) può patchare credenziali, LSM hooks, o dispatch tables without ever leaking the true KASLR slide. L’unica limitazione è che .text è mappata non eseguibile nella linear map, quindi gadget hunting richiede ancora un tradizionale leak.

PFN spraying when the kernel physbase is randomized

Vendor come Samsung randomizzano il PFN di caricamento del kernel, ma la static linear map è ancora sfruttabile perché l’allocazione dei PFN non è totalmente casuale:

  1. Spray user pages: mmap() ~5 GiB, accedi a ogni pagina per forzarne il fault.
  2. Harvest PFNs: leggi /proc/pagemap per ogni pagina (o usa un altro PFN leak) per raccogliere la lista dei PFN di backing.
  3. Repeat and profile: reboot, riesegui 100×, costruisci un istogramma che mostri quante volte ogni PFN è stato controllato dall’attacker. Alcuni PFN risultano white-hot (allocati 100/100 volte poco dopo il boot).
  4. Convert PFN → kernel VA:
  • phys = (pfn << PAGE_SHIFT) + offset_in_page
  • virt = phys_to_virt(phys)
  1. Forge kernel objects in those pages e indirizza i puntatori della vittima (UAF, overflow, ecc.) verso gli indirizzi noti nella linear-map.

Poiché la linear map è memoria identity-mapped e RW, questa tecnica permette di posizionare dati completamente controllati dall’attacker in VA kernel deterministici anche quando la vera base del kernel si muove. Exploits possono precostruire fake file_operations, cred, o strutture di refcount dentro le pagine spruzzate e poi pivotare puntatori kernel esistenti verso di esse.

Practical workflow for arm64 Android exploits

  1. Raccolta informazioni
  • Ottieni root o usa un primitive di lettura kernel per dumpare memstart_addr, _stext, e il simbolo target da /proc/kallsyms.
  • Su Pixel, fidati della physbase statica da /proc/iomem; su altri dispositivi, prepara il PFN profiler.
  1. Calcolo degli indirizzi
  • Applica la matematica dell’offset sopra e memorizza le VA della linear-map risultanti nel tuo exploit.
  • Per il PFN spraying, mantieni una lista di PFN “affidabili” che ricadono ripetutamente nella memoria controllata dall’attacker.
  1. Integrazione dell’exploit
  • Quando è disponibile un arbitrary write, patcha direttamente obiettivi come modprobe_path, init_cred, o security ops arrays agli indirizzi precomputati.
  • Quando esiste solo una corruzione di heap, costruisci fake objects nelle pagine note-supervisionate e ripunta i puntatori vittima a quelle linear-map VAs.
  1. Verifica
  • Usa bpf_arb_read o qualsiasi primitive di lettura sicura per verificare che l’indirizzo calcolato contenga i byte attesi prima di scritture distruttive.

Questo workflow elimina la fase KASLR-leak per exploit kernel data-centric su Android, riducendo drasticamente la complessità dell’exploit e migliorandone l’affidabilità.

References

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks