Mendapatkan eksekusi kode kernel pada Pixel 8 dengan MTE aktif

 (github.blog)
1 poin oleh GN⁺ 2024-03-20 | 1 komentar | Bagikan ke WhatsApp
  • CVE-2023-6241 adalah bug logika pada unit manajemen memori GPU Arm Mali yang memungkinkan aplikasi Android berbahaya mencapai eksekusi kode kernel arbitrer dan memperoleh hak akses root bahkan pada Pixel 8 dengan MTE kernel aktif
  • Perangkat yang terdampak adalah perangkat GPU Arm Mali terbaru yang menggunakan Command Stream Frontend (CSF), termasuk Google Pixel 7 dan Pixel 8
  • Kerentanan ini bekerja dengan memanfaatkan jeda singkat saat lock dilepas selama perluasan memori JIT untuk menciptakan ketidaksesuaian antara pemetaan GPU dan array backing page
  • Eksploit memanfaatkan pemetaan GPU yang tersisa pada backing page yang sudah dibebaskan, lalu membuat halaman tersebut digunakan kembali sebagai PGD konteks GPU, kemudian memetakan memori kernel dan kode kernel
  • MTE mendeteksi ketidakcocokan tag pointer dan memori, tetapi alur serangan ini berjalan di luar cakupan perlindungan MTE karena GPU mengakses alamat fisik secara langsung

Cakupan kerentanan dan status patch

  • CVE-2023-6241 adalah kerentanan pada GPU Arm Mali yang memungkinkan aplikasi Android berbahaya memperoleh eksekusi kode kernel arbitrer dan hak akses root pada perangkat
  • Dilaporkan ke Arm pada 15 November 2023, dan diperbaiki di Arm Mali driver r47p0 yang dirilis pada 14 Desember 2023
  • Perbaikan Android disertakan dalam pembaruan keamanan Maret 2024
  • Yang terdampak adalah perangkat GPU Arm Mali terbaru yang menggunakan fitur CSF (Command Stream Frontend), dengan Google Pixel 7 dan Pixel 8 disebut sebagai contoh
  • Eksploit terkonfirmasi berjalan bahkan saat MTE kernel diaktifkan pada Pixel 8

Model pertahanan Arm64 MTE

  • MTE (Memory Tagging Extension) adalah fitur perangkat keras pada prosesor Arm modern yang membandingkan tag pointer dan blok memori untuk mendeteksi kerusakan memori
  • Pointer Arm64 berukuran 64-bit, tetapi ruang alamat aplikasi yang sebenarnya biasanya 52-bit atau kurang, sehingga sebagian bit atas dapat digunakan untuk menyimpan tag
  • Pada overflow linear, tag blok memori yang berdekatan bisa berbeda dari tag pointer, dan pada use-after-free ketidakcocokan dapat terjadi akibat perubahan tag saat pembebasan dan realokasi
  • Berbeda dengan mitigasi tahap akhir seperti kCFI, MTE adalah mitigasi tahap awal yang bertujuan menangkap kerusakan memori pada saat pertama kali terjadi
  • Karena jumlah bit tag terbatas, tabrakan tidak dapat dihindari, tetapi bahkan dengan tag 4-bit peluang sukses acak turun menjadi 1/16
  • Jika nilai pointer dan blok memori bocor melalui serangan side-channel seperti Spectre, penyerang dapat menebak tag yang benar untuk melewati MTE, tetapi kebocoran semacam itu umumnya hanya mungkin bagi penyerang lokal
  • Saat ini hanya Google Pixel 8 yang mengizinkan aktivasi MTE melalui opsi pengembang, dan MTE dinonaktifkan secara default
  • Mengaktifkan MTE di kernel memerlukan prosedur tambahan

Race condition pada memori Mali JIT

  • Aplikasi pengguna yang memakai driver GPU Mali membuka file driver dan membuat serta menginisialisasi objek kernel kbase_context melalui pemanggilan ioctl
  • kbase_context mengelola berbagai jenis memori yang dibagikan antara perangkat GPU dan aplikasi user space
  • Region memori GPU direpresentasikan sebagai kbase_va_region; nr_pages menunjukkan ukuran virtual, sedangkan gpu_alloc->nents menunjukkan jumlah backing page yang sebenarnya
  • Memori JIT adalah native memory yang siklus hidupnya dikelola oleh driver kernel, dan aplikasi dapat mengalokasikan atau membebaskannya lewat perintah GPU
  • Pada GPU CSF, perintah perangkat lunak dan perangkat keras ditempatkan pada antrean yang berbeda
    • KBASE_IOCTL_KCPU_QUEUE_CREATE dapat digunakan untuk membuat kbase_kcpu_command_queue
    • KBASE_IOCTL_KCPU_QUEUE_ENQUEUE digunakan untuk memasukkan perintah ke antrean
    • BASE_KCPU_COMMAND_TYPE_JIT_ALLOC dan BASE_KCPU_COMMAND_TYPE_JIT_FREE digunakan untuk alokasi dan pembebasan JIT
  • kbase_jit_allocate mencari region yang dapat digunakan kembali dari pool memori JIT yang sudah dibebaskan, dan jika ukuran fisik tidak mencukupi maka backing page akan ditambah lewat kbase_jit_grow
  • kbase_jit_grow dapat melepaskan kctx->reg_lock dan kctx->mem_partials_lock untuk sementara selama pemanggilan kbase_mem_pool_grow
  • kctx->reg_lock melindungi akses bersamaan ke region memori, sehingga periode saat lock dilepas menjadi jendela race

Alur pemicu CVE-2023-6241

  • Jika GPU mengakses alamat region memori yang tidak didukung backing halaman fisik, akan terjadi fault akses memori GPU
  • kbase_mmu_page_fault_worker dapat memeriksa apakah region bisa diperluas, lalu segera mengalokasikan dan memetakan backing page yang diperlukan
  • Saat dibuat, region JIT memenuhi kondisi GROWABLE_FLAGS_REQUIRED yang mencakup KBASE_REG_PF_GROW dan KBASE_REG_GPU_WR
  • Flag KBASE_REG_DONT_NEED yang ditambahkan saat region JIT dibebaskan akan dihapus oleh kbase_mem_evictable_unmake pada awal kbase_jit_grow
  • Akibatnya, jika fault halaman GPU dibuat pada region JIT yang sama selama jendela race saat kbase_mem_pool_grow berjalan, fault handler dapat memperluas region tersebut
  • Jika fault handler mengubah reg->gpu_alloc->nents, maka nilai old_size dan delta yang sebelumnya disimpan oleh kbase_jit_grow menjadi tidak selaras dengan kondisi sebenarnya
  • Setelah itu, kbase_alloc_phy_pages_helper_locked dan kbase_mem_grow_gpu_mapping melakukan alokasi backing page dan pemetaan GPU menggunakan nilai stale, sehingga timbul ketidaksesuaian antara pemetaan GPU dan array pages
  • Race ini mudah dimenangkan karena kbase_mem_pool_grow melibatkan alokasi memori yang besar

Perubahan metode serangan setelah patch GHSL-2023-005

  • Pada kerentanan sebelumnya GHSL-2023-005, thread lain dapat mengecilkan region JIT dengan KBASE_IOCTL_MEM_COMMIT sehingga old_size dan delta menjadi tidak valid
  • Setelah patch GHSL-2023-005, ukuran memori JIT tidak lagi dapat diubah melalui KBASE_IOCTL_MEM_COMMIT ioctl
  • Pada CVE-2023-6241, selama jendela race region tidak bisa dikecilkan, hanya bisa diperbesar
  • Jika hanya diperbesar, akibat langsungnya hanyalah beberapa backing page terakhir tidak dipetakan ke GPU; bentuk pemetaan kontinu dari awal tetap terjaga sehingga tidak langsung bermasalah
  • Eksploit membuat pemetaan baru setelah unmapped gap lewat fault GPU tambahan, lalu memanfaatkan pembebasan JIT berikutnya untuk menempatkan titik shrink di dalam gap tersebut sehingga tercipta kondisi yang bisa dieksploitasi

Asumsi rapuh dalam pelepasan pemetaan GPU

  • kbase_mmu_teardown_pgd_pages menelusuri page table GPU sambil menandai entri sebagai invalid untuk menghapus pemetaan alamat GPU
  • Fungsi ini mengasumsikan bahwa jika PTE level tinggi invalid, maka seluruh rentang alamat besar yang dicakup entri itu sudah unmapped dan bisa dilewati
  • Satu PTE level 2 mencakup rentang 512 halaman
  • Pada kbase_va_region normal, alamat virtual yang dipetakan selalu kontinu sejak awal region dan tidak memiliki gap di tengah, sehingga perilaku skip ini aman
  • Eksploit CVE-2023-6241 membuat unmapped gap di antara pemetaan lalu menempatkan titik awal shrink di dalam gap itu
  • kbase_mmu_teardown_pgd_pages menemukan PTE level 2 yang invalid dan melewati 512 halaman, tetapi sebagian alamat di belakangnya sebenarnya masih bisa dipetakan
  • Alamat GPU yang terlewat secara keliru tetap mempertahankan akses ke halaman fisik tersebut bahkan setelah backing page dibebaskan

Proses menuju eksekusi kode kernel

  • Saat region JIT dibebaskan, backing page dikembalikan, tetapi pemetaan GPU yang tertinggal masih dapat terus mengakses halaman yang sudah dibebaskan
  • Backing page yang dibebaskan kemudian dapat digunakan kembali sebagai halaman kernel lain
  • Salah satu teknik yang digunakan adalah membuat backing page yang dibebaskan itu dipakai ulang sebagai PGD (page table global directory) milik kbase_context GPU
  • Alokasi backing page oleh driver Mali dilakukan secara hierarkis
    • Mula-mula halaman diambil dari kbase_mem_pool milik kbase_context saat ini
    • Jika tidak cukup, digunakan pool->next_pool
    • Jika masih tidak cukup, halaman dialokasikan langsung melalui kernel buddy allocator
  • pool->next_pool adalah pool memori yang dikelola driver Mali dan dibagikan oleh semua kbase_context, serta juga dipakai untuk alokasi PGD konteks GPU
  • Jika halaman yang dibebaskan digunakan ulang sebagai PGD, maka alamat GPU yang tersisa dapat digunakan untuk menulis kembali PGD tersebut dari GPU
  • Dengan menulis ulang PGD, memori kernel arbitrer dan kode kernel dapat dipetakan ke GPU
  • Pada kondisi ini, penulisan ulang kode kernel memungkinkan eksekusi kode kernel arbitrer, dan data kernel dapat dibaca maupun ditulis untuk mengubah credential proses serta menonaktifkan SELinux
  • Eksploit untuk Pixel 8 dan catatan penyiapannya dipublikasikan di repositori GitHub Security Lab

Mengapa MTE bisa dilewati

  • Alur eksploit ini tidak memerlukan tahap bypass khusus untuk MTE
  • MTE memeriksa apakah tag pada blok memori yang ditunjuk oleh pointer cocok untuk menangkap dereference yang salah
  • Saat CVE-2023-6241 dipicu, terjadi ketidaksesuaian antara array pages dan pemetaan GPU, tetapi jika dilihat terpisah masing-masing tidak memiliki entri invalid
  • Ketika kbase_mmu_teardown_pgd_pages melewati pelepasan pemetaan GPU, alamat fisik dari halaman memori yang sudah dibebaskan tetap berada di page table GPU
  • Saat GPU mengakses halaman yang telah dibebaskan itu, GPU mengakses alamat fisik secara langsung sehingga tidak melalui pemeriksaan dereference pointer
  • Pengaruh MTE terhadap akses memori GPU juga tidak sepenuhnya jelas
  • Akibatnya, bug ini melewati perlindungan MTE dengan memanfaatkan jalur di mana koprosesor GPU mengakses memori fisik secara langsung

Permukaan serangan yang masih tersisa setelah MTE

  • CVE-2023-6241 menunjukkan bahwa bahkan pada Pixel 8 dengan MTE kernel aktif, satu bug saja masih dapat menghasilkan eksekusi kode kernel arbitrer
  • MTE adalah kemajuan penting dalam mitigasi kerusakan memori dan dapat membuat banyak kerentanan semacam itu tidak bisa dieksploitasi, tetapi bukan pertahanan yang sempurna
  • Dalam kasus ini, GPU melewati MTE dengan mengakses memori fisik secara langsung
  • Semakin banyak mitigasi perangkat keras dan perangkat lunak di sisi CPU, koprosesor dan driver kernelnya dapat tetap menjadi permukaan serangan yang kuat

Bacaan terkait

1 komentar

 
GN⁺ 2024-03-20
Komentar Hacker News

  • Intinya di sini adalah GPU sudah lama menjadi sumber masalah bagi Android.
    GPU punya hak akses yang sangat kuat ke AP, sehingga pada praktiknya bisa melewati mitigasi yang dipasang di depan. Bug pada kode pemetaan driver berujung pada primitive serangan yang kuat, dan sudah berulang kali dieksploitasi dalam eksploit liar di dunia nyata. Pada akhirnya, sepertinya sulit ada perubahan besar sebelum arsitekturnya dirancang ulang.

    • Menurut saya GPU mobile yang setengah matang harus berhenti memasukkan MMU sendiri dan memakai MMU input/output standar.
    • AP di sini maksudnya apa?

  • Hal menarik dari kerentanan ini adalah adanya bug logika di unit manajemen memori GPU Arm Mali, dan bahwa bug ini bisa melewati Memory Tagging Extension.
    Namun bagian lain tulisannya tampak menjelaskan bahwa penyebab sebenarnya adalah race condition, sementara use-after-free adalah akibatnya.

  • Apakah instalasi GrapheneOS sebelum pembaruan Maret juga terdampak?

    • Salah satu tujuan utama GrapheneOS adalah mendistribusikan pembaruan keamanan secepat mungkin, jadi jika sudah ditambal di upstream, hampir pasti sudah termasuk di GrapheneOS.
      Kadang mereka mengadopsi level patch keamanan AOSP sebelum rilis, atau melakukan backport perbaikan keamanan dari sumber AOSP atau kernel yang belum dipublikasikan.
    • Ini tampaknya terkait masalah yang dekat dengan perangkat keras di dalam GPU, mungkin masalah firmware, jadi saya kira masih akan terdampak setelah pembaruan Maret. Pembaruan itu kan terkait stack Bluetooth.
      Koreksi: abaikan. Saya tertukar dengan tulisan terbaru di blog GrapheneOS tentang “menemukan masalah saat MTE juga diterapkan ke semua aplikasi sistem”. GrapheneOS mengambil “level patch keamanan lengkap 2024-03-05” pada rilis 2024030600, jadi tampaknya patch ini juga sudah termasuk.

  • Keamanan memori probabilistik Arm MTE adalah batu loncatan menuju perangkat keras deterministik CHERI, https://saaramar.github.io/memory_safety_blogpost_2022/ dan https://news.ycombinator.com/item?id=39668053
    Mitigasi yang tepat harus menargetkan primitive serangan tingkat pertama, yaitu akar penyebab bug. Solusi perangkat keras mencakup CHERI (Morello, CheriIoT), MTE; mitigasi perangkat lunak mencakup kalloc_type+dataPAC, AUTOSLAB, Firebloom, GuardedMemcpy, CastGuard, pengurangan attack surface; dan bahasa pemrograman yang aman mencakup Rust dan Swift. MTE dan CHERI saling melengkapi dengan baik dan membantu menghilangkan bug di area ini dari akar penyebabnya. MSR, MSRC, dan Azure Silicon mendorong penyusutan CHERI hingga spesifikasi core RISC-V terkecil, RISC-V32E
    Microsoft Research telah merilis stack perangkat keras/perangkat lunak CHERI untuk perangkat IoT sebagai open source, https://msrc.microsoft.com/blog/2023/02/first-steps-in-cheri...
    Mikrokontroler berbasis CHERI bertujuan memperoleh jaminan keamanan yang sangat kuat dengan merancang bersama instruction set architecture (ISA), application binary interface (ABI), model isolasi, dan inti stack perangkat lunak. Mikrokontroler ini mencapai mitigasi deterministik untuk keamanan spasial melalui fitur CHERI-ISA, mitigasi deterministik untuk keamanan temporal heap dan stack antar-kompartemen melalui load barrier, zeroing, reclamation, dan kontrol aliran informasi 1-bit, serta kompartementalisasi halus melalui fitur CHERI-ISA tambahan dan monitor kecil
    David Chisnall, U of Cambridge, https://lobste.rs/s/gnjx2n/c_can_be_memory_safe#c_9ohzku via https://eclypsium.com/blog/a-faster-path-to-memory-safety-ch...
    “Ada sekitar 13 miliar baris kode C/C++ open source yang masuk ke berbagai trusted computing base, dan jumlahnya lebih besar jika kode proprietary disertakan. Bahkan jika semua orang berhenti menulis C/C++ sekarang dan semua software engineer fokus menulis ulang kode legacy dalam bahasa yang aman, butuh 5–10 tahun untuk mengganti semuanya, dan kemungkinan besar akan muncul banyak bug logika saat kode yang sudah lama teruji diganti dengan kode baru yang membutuhkan algoritma dan struktur data berbeda agar sesuai dengan idiom yang diizinkan oleh bahasa aman.”
    “Jika kita tidak menulis ulang dan hanya berhenti menulis kode C/C++, pada laju penggantian kode yang umum, butuh sekitar 50 tahun sampai trusted computing base sepenuhnya aman. Jika tidak semua orang sepakat berhenti memakai C/C++, minimal 100 tahun.”
    “Sebaliknya, jika produsen CPU besar merilis CPU CHERI dalam 5 tahun, maka tanpa programmer mengubah perilaku pun, dalam 15 tahun sejak hari ini sebagian besar mesin, terutama mesin bernilai tinggi, akan memiliki keamanan memori.”

    • Jika tertarik pada CHERI untuk penggunaan yang mirip embedded/IoT, lowRISC sedang membuat beberapa platform evaluasi berbasis FPGA untuk CHERIoT: https://www.sunburst-project.org/
      Yang pertama adalah sistem Sonata: https://github.com/lowRISC/sonata-system. Ini terdiri dari PCB khusus dengan FPGA serta berbagai periferal dan header. Desain PCB sudah selesai dan rencananya akan tersedia lewat Mouser; bahkan layout board-nya open source sehingga Anda bisa merakitnya sendiri jika mau. Saat ini mereka sedang mengerjakan RTL untuk FPGA. Setelah selesai, Anda akan mendapatkan sistem bergaya mikrokontroler berbasis CHERIoT lengkap dengan dokumentasi dan tool
      Selain itu, mereka juga membuat sistem Symphony yang menggabungkan Sonata dengan root of trust OpenTitan Earl Grey: https://github.com/lowRISC/symphony-system
    • Ada juga Solaris SPARC ADI. Karena kondisi Oracle dan Solaris SPARC saat ini, kebanyakan orang melupakannya, padahal itu disayangkan
    • Ini adalah bug perangkat keras di luar CPU, jadi saya tidak tahu bagaimana CHERI bisa membantu
      Selain itu, terakhir kali saya lihat, CHERI belum sound. Di atasnya pun masih bisa menulis bug memori; apakah itu sudah diperbaiki sekarang?
    • “5–10 tahun untuk mengganti semuanya” terdengar terlalu optimistis jika yang dimaksud adalah hitungan tahun
      Debat soal bike shed saja rasanya bisa memakan waktu selama itu
    • Masalah mendasarnya tampaknya pengguna menjalankan kode berbahaya dan mengeksploitasi suatu tabrakan hash MMU
      Eksploit ini sepertinya bisa ditulis dalam sebagian besar bahasa, termasuk Rust

  • Perangkat kerasnya seburuk itu? Astaga...

    • Perangkat keras GPU penuh dengan bug. Mereka hanya melakukan respin perangkat keras jika masalahnya tidak bisa diakali di driver dengan biaya yang dapat diterima
      Cara ini memungkinkan karena GPU tidak mengizinkan akses perangkat keras yang relatif langsung seperti CPU
    • Ini adalah bug driver yang berjalan di CPU

  • Riset dan tulisannya bagus, tapi agak tak terduga sekaligus menyenangkan melihatnya muncul di blog GitHub
    Ada yang tahu “alasan bisnis” GitHub melakukan riset seperti ini? Bukan berarti harus selalu ada alasan bisnis, tetapi cukup mengejutkan melihatnya di sini

    • Man Yue Mo pernah bekerja di Semmle sebelum diakuisisi GitHub (https://blog.sonatype.com/steps-to-responsible-disclosure, https://github.blog/2019-09-18-github-welcomes-semmle/)
      Fungsi riset itu berlanjut menjadi GitHub Security Lab. Semmle membuat CodeQL, dan sekarang disediakan oleh GitHub (https://docs.github.com/en/code-security/code-scanning/intro...). GitHub dan Microsoft ingin mengaitkan CodeQL dengan “wawasan keamanan yang mendalam” (https://www.microsoft.com/en-us/security/blog/2023/11/02/ann...)
      Jadi mereka terus mendanai riset keamanan yang inovatif seperti ini, dan para praktisi keamanan di industri berterima kasih karenanya
    • Pekerjaan ini berasal dari Security Lab milik GitHub: https://securitylab.github.com/
    • Setelah diakuisisi Microsoft, mereka punya sumber daya untuk mensponsori riset semacam ini
      GitHub juga punya aplikasi, dan keamanan aplikasi itu tidak berada di luar cakupan GitHub. Jika penyerang bisa memasang aplikasi yang bersembunyi di ponsel, ia bisa melakukan banyak hal seolah-olah sebagai pengguna. Jika korbannya orang yang punya pengaruh di GitHub, dampaknya bisa cukup besar, jadi mencari kerentanan seperti ini juga menguntungkan bagi GitHub
    • GitHub juga memiliki runner Actions ter-hosting untuk Arm
      Jadi mereka mungkin tertarik untuk memeriksa dan memvalidasi fitur keamanan perangkat keras Arm untuk sandboxing berbasis MTE
    • Menurut saya ini pada dasarnya lebih dekat ke riset dasar [0]
      Kalau dilihat secara langsung, produk bernama GitHub tidak selalu membutuhkan pakar keamanan Android. Namun dalam jangka panjang ada potensi manfaatnya
      [0]: https://en.wikipedia.org/wiki/Basic_research

  • Mengejutkan bahwa belum ada contoh orang membuat ponsel dan CPU dengan GPU yang sangat minim atau bahkan tanpa GPU sama sekali lalu menyebutnya ponsel bisnis
    Keunggulannya dari sisi keamanan, biaya, dan konsumsi daya tampak jelas

    • Kekurangan yang jelas adalah tidak adanya layar sentuh beresolusi tinggi, sehingga kita kembali ke Blackberry atau Palm Treo. Perangkat seperti itu memang pernah dijual sebagai ponsel bisnis