Linux arm64 Static Linear Map KASLR Bypass

Tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks

Przegląd

Jądra Androida kompilowane dla arm64 niemal powszechnie włączają CONFIG_ARM64_VA_BITS=39 (3-poziomowe stronicowanie) oraz CONFIG_MEMORY_HOTPLUG=y. Przy jedynie 512 GiB dostępnej przestrzeni wirtualnej jądra, deweloperzy Linuksa zdecydowali się zakotwiczyć mapę liniową na najniższym możliwym kernel VA, tak aby przyszła pamięć dodawana przez hot-plug mogła po prostu rozszerzać mapowanie w górę. Od commita 1db780bafa4c arm64 przestał nawet próbować zrandomizować to położenie, co oznacza:

  • PAGE_OFFSET = 0xffffff8000000000 jest wkompilowany.
  • PHYS_OFFSET jest pobierany z eksportowanego memstart_addr, który na standardowych urządzeniach z Androidem jest w praktyce stały (0x80000000 obecnie).

W konsekwencji, każda strona fizyczna ma deterministyczny adres wirtualny mapy liniowej, niezależny od KASLR slide:

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

Jeśli atakujący może poznać lub wpłynąć na adres fizyczny (kernel object, PFN z /proc/pagemap, a nawet stronę kontrolowaną przez użytkownika), natychmiast zna odpowiadający mu kernel virtual address bez leaking the randomized primary kernel mapping.

Odczyt memstart_addr i potwierdzenie transformacji

memstart_addr jest eksportowany w /proc/kallsyms i można go odczytać na urządzeniach z rootem lub za pomocą dowolnego kernel-read primitive. Project Zero użyło pomocnika tracing-BPF Janna Horna (bpf_arb_read), aby zrzucić go bezpośrednio:

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

The bytes 00 00 00 80 00 00 00 00 confirm memstart_addr = 0x80000000. Once PAGE_OFFSET and PHYS_OFFSET are pinned, the arm64 linear map is a static affine transform of any physical address.

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

Wiele urządzeń Pixel nadal dekompresuje kernel przy phys_kernel_base = 0x80010000 przy każdym bootcie (widoczne w /proc/iomem). Połączenie tego ze statyczną transformacją daje adresy stabilne między rebootami dla dowolnego symbolu danych:

  1. Zanotuj z /proc/kallsyms (lub z dokładnego vmlinux) zrandomizowany wirtualny adres _stext oraz adres docelowego symbolu.
  2. Oblicz przesunięcie: offset = sym_virt - _stext_virt.
  3. Dodaj statyczny boot-time physbase: phys_sym = 0x80010000 + offset.
  4. Konwertuj na VA w linear-map: virt_sym = phys_to_virt(phys_sym).

Przykład (modprobe_path on a Pixel 9): offset = 0x1fe2398, phys = 0x81ff2398, virt = 0xffffff8001ff2398. Po wielokrotnych rebootach bpf_arb_read 0xffffff8001ff2398 zwraca te same bajty, więc payloady eksploitów mogą traktować 0xffffff8000010000 jako syntetyczną, nienaciskaną (non-randomized) bazę dla wszystkich przesunięć .data.

To mapowanie jest RW, więc każdy primitive, który potrafi umieścić dane atakującego w kernelowej przestrzeni wirtualnej (double free, UAF, non-paged heap write, itd.) może patchować credentials, LSM hooks lub dispatch tables bez ever leaking the true KASLR slide. Jedynym ograniczeniem jest to, że .text jest mapowane jako non-executable w linear map, więc gadget hunting nadal wymaga tradycyjnego leak.

PFN spraying when the kernel physbase is randomized

Dostawcy tacy jak Samsung randomizują kernel load PFN, ale statyczny linear map nadal można nadużyć, ponieważ alokacja PFN nie jest całkowicie losowa:

  1. Spray user pages: mmap() ~5 GiB, dotknij każdą stronę aby wymusić page fault.
  2. Harvest PFNs: read /proc/pagemap for each page (or use another PFN leak) aby zebrać listę backing PFNów.
  3. Repeat and profile: reboot, uruchom ponownie 100×, zbuduj histogram pokazujący jak często każdy PFN był kontrolowany przez atakującego. Niektóre PFNy są white-hot (alokowane 100/100 razy krótko po bootcie).
  4. Convert PFN → kernel VA:
  • phys = (pfn << PAGE_SHIFT) + offset_in_page
  • virt = phys_to_virt(phys)
  1. Forge kernel objects in those pages i nakieruj wskaźniki ofiary (UAF, overflow, itd.) na znane adresy w linear-map.

Ponieważ linear map jest identity-mapped RW pamięcią, ta technika pozwala umieścić w pełni attacker-controlled dane pod deterministycznymi kernelowymi VA nawet gdy prawdziwa baza kernela się przesuwa. Exploity mogą przygotować fałszywe file_operations, cred lub struktury refcount wewnątrz spryskanych stron i następnie pivotować istniejące kernelowe wskaźniki na nie.

Practical workflow for arm64 Android exploits

  1. Info gathering
  • Uzyskaj root lub użyj kernel read primitive, aby zrzucić memstart_addr, _stext i docelowy symbol z /proc/kallsyms.
  • Na Pixelach zaufaj statycznemu physbase z /proc/iomem; na innych urządzeniach przygotuj PFN profiler.
  1. Address calculation
  • Zastosuj powyższą matematykę przesunięć i zapisz wynikowe linear-map VA w swoim exploicie.
  • Dla PFN spraying trzymaj listę “reliable” PFNów, które powtarzalnie lądują w pamięci atakującego.
  1. Exploit integration
  • Gdy dostępny jest arbitrary write, bezpośrednio patchuj cele takie jak modprobe_path, init_cred lub security ops arrays pod wcześniej obliczonymi adresami.
  • Gdy istnieje tylko heap corruption, zbuduj fałszywe obiekty w nadzorowanych stronach i przekaż wskaźniki ofiary na te linear-map VA.
  1. Verification
  • Użyj bpf_arb_read lub dowolnego bezpiecznego read primitive, aby sanity-checkować, że obliczony adres zawiera oczekiwane bajty przed destrukcyjnymi zapisami.

Ten workflow eliminuje etap KASLR-leak dla exploitów zorientowanych na dane w kernelu na Androidzie, co znacząco obniża złożoność exploitów i poprawia niezawodność.

References

Tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks