Injeksi Privilege Branch: Mengeksploitasi Race Condition pada Prediktor Branch

 (comsec.ethz.ch)
1 poin oleh GN⁺ 2025-05-14 | 1 komentar | Bagikan ke WhatsApp
  • Branch Privilege Injection adalah kerentanan yang kembali memungkinkan bypass terhadap pertahanan perangkat keras keluarga Spectre-BTI yang telah bertahan sekitar 6 tahun, melalui race condition pada prediktor branch di CPU Intel
  • Inti serangan ini adalah bahwa pembaruan prediktor branch diproses secara asinkron terhadap alur instruksi, dan dalam kondisi tertentu dapat diterapkan terlambat hingga puluhan sampai ratusan siklus
  • Jika pembaruan yang tertunda masih tersisa saat perpindahan privilege atau eksekusi IBPB, pembaruan itu kemudian dapat dikaitkan ke domain keamanan yang salah, sehingga jaminan keamanan eIBRS dan IBPB dapat rusak
  • Tim peneliti mendemonstrasikan serangan end-to-end yang membocorkan memori arbitrer pada kecepatan 5.6KiB/s di Intel Raptor Lake generasi ke-13, dengan seluruh mitigasi bawaan aktif di Ubuntu 24.04
  • Pembaruan microcode Intel memblokir primitive deteksi kerentanan dalam evaluasi di Alder Lake, dengan overhead hingga 2.7%

Kondisi agar Branch Privilege Injection dapat terjadi

  • Branch Privilege Injection adalah serangan branch target injection, yaitu serangan yang kembali memungkinkan efektivitas Spectre-BTI di lingkungan Intel
  • Mitigasi perangkat keras Intel telah mencegah jenis serangan ini selama sekitar 6 tahun, tetapi riset kali ini menunjukkan bahwa race condition pada CPU Intel dapat menggoyahkan pertahanan tersebut
  • Serangan ini didasarkan pada dua pengamatan
    • Prediktor branch pada prosesor Intel diperbarui secara asinkron terhadap alur instruksi
      • Dalam kondisi tertentu, pembaruan dapat tertunda puluhan atau ratusan siklus
      • Pembaruan asinkron itu sendiri bukan kerentanan, melainkan sebuah fitur
    • Selama operasi yang penting bagi keamanan, sinkronisasi antara prediktor branch dan alur instruksi tidak memadai
      • Saat berpindah dari mode pengguna ke kernel, atau dari guest ke hypervisor, pembaruan mungkin masih sedang berlangsung
      • Bahkan selama eksekusi IBPB, pembaruan yang sedang berjalan dapat tetap tersisa
      • Jika pembaruan seperti itu tiba setelah perpindahan privilege, pembaruan tersebut dihubungkan ke mode privilege baru, bukan privilege sebelumnya
  • Nama untuk jenis kerentanan ini adalah Branch Predictor Race Conditions

Mitigasi yang jebol dan cakupan dampaknya

  • eIBRS adalah mitigasi Spectre-BTI dari Intel yang diperkenalkan pada semua prosesor sejak Coffee Lake Refresh generasi ke-9
    • Tujuannya adalah memisahkan prediksi indirect branch berdasarkan domain keamanan yang berbeda
    • Setiap prediksi dirancang untuk dikaitkan dengan domain tempat prediksi itu dibuat, lalu hanya prediksi dari domain saat ini yang digunakan
    • Jika pembaruan yang masih berjalan selama perpindahan privilege dikaitkan ke domain keamanan baru, pengaitan ini dapat dimanipulasi
  • IBPB adalah mekanisme yang digunakan untuk memisahkan sandbox atau virtual machine yang tidak saling percaya di dalam domain keamanan perangkat keras yang sama
    • Mekanisme ini menyediakan fungsi untuk membatalkan semua prediksi indirect branch
    • Pembaruan yang masih berjalan tidak di-flush oleh IBPB, sehingga tetap dapat disimpan di prediktor branch setelah invalidasi
  • Cakupan dampak menunjukkan perbedaan menurut generasi dan arsitektur
    • Semua prosesor Intel sejak Coffee Lake Refresh generasi ke-9 terdampak oleh Branch Privilege Injection
    • Prediksi bypass IBPB diamati hingga mundur ke Kaby Lake generasi ke-7
    • Tidak ditemukan masalah pada sistem AMD dan ARM yang dievaluasi
    • Serangan proof-of-concept dibuat untuk Linux, tetapi karena masalah dasarnya ada pada perangkat keras, sistem operasi yang berjalan di perangkat keras terdampak juga akan terpengaruh

Mitigasi, biaya performa, dan materi publik

  • Disarankan memasang pembaruan sistem operasi dan BIOS terbaru
  • Intel telah mengembangkan pembaruan microcode untuk prosesor yang terdampak, dan tim peneliti mengevaluasinya di Alder Lake
    • Mitigasi microcode memblokir primitive deteksi kerentanan
    • Menunjukkan overhead hingga 2.7% di Alder Lake
  • Alternatif mitigasi perangkat lunak juga dievaluasi
    • Overhead 1.6% pada Coffee Lake Refresh
    • Overhead 8.3% pada Rocket Lake
  • Detail teknis selengkapnya dapat dilihat di paper
  • Paper Branch Privilege Injection dijadwalkan dipresentasikan di USENIX Security 2025, dan presentasi di Black Hat USA 2025 juga dijadwalkan
  • Kode sumber untuk serangan dan eksperimen dipublikasikan di github

Bacaan terkait

1 komentar

 
GN⁺ 2025-05-14
Komentar Hacker News

  • Posting blog para peneliti: https://comsec.ethz.ch/research/microarch/branch-privilege-i...
    Makalah: https://comsec.ethz.ch/wp-content/files/bprc_sec25.pdf

    • Contoh dampak: Rüegge menjelaskan bahwa seiring waktu, penyerang bisa membaca seluruh isi memori, dan dengan memicu error berulang kali dapat mencapai kecepatan baca lebih dari 5000 byte per detik
      Dalam skenario serangan, pada akhirnya tinggal menunggu waktu sampai informasi dari seluruh memori CPU jatuh ke tangan yang salah
    • Akan bagus kalau URL judul diganti ke posting blog itu. Siaran persnya bukan cuma tidak berguna, tapi sampai merugikan

  • Tulisan yang bagus. Ringkasnya, pembaruan branch predictor bisa ditunda cukup lama setelah instruksi branch pensiun (retire)
    Kalau tidak begitu, pensiunnya instruksi branch akan memakan waktu lebih lama, jadi ini masuk akal. Instruksi serialisasi dispatch juga tampaknya tidak menghentikan pipeline karena adanya pembaruan tertunda pada status predictor, dan ini wajar karena “commit hasil instruksi branch” dan “commit hasil prediksi” memang sudah dibedakan
    Instruksi perubahan privilege juga tidak menghentikan pipeline karena pembaruan tertunda, tetapi itu hanya sah jika bisa dijamin bahwa level privilege saat membuat prediksi dan saat melakukan commit konsisten. Kalau tidak, prediksi yang dibuat oleh kode pada satu level privilege bisa di-commit ke status yang digunakan pada level privilege lain
    Mungkin ini masalah yang sulit karena di dalam pipeline, level privilege saat ini bukan satu nilai yang tunggal dan jelas

  • Senang melihat Kaveh Razavi. Dulu ia mengajar di Vrije Universiteit Amsterdam, dan mata kuliah Hardware Security-nya benar-benar keren karena membahas hal-hal seperti ini secara mendalam

    • Beberapa tahun lalu saya mencari mata kuliah ini dan mata kuliah lain di Vrije yang terkait malware, tetapi saat itu hampir tidak ada materi publik
      Saya penasaran apakah rekaman resmi atau catatannya tersedia online

  • Ada yang tahu ini berhubungan seperti apa dengan serangan Training Solo yang baru saja dipublikasikan? https://www.vusec.net/projects/training-solo/

    • Keduanya mengeksploitasi Spectre V2, tetapi caranya berbeda
      Training Solo masuk ke kernel dan mengubah level privilege, lalu dengan “self-training” membuat branch salah diprediksi ke arah disclosure gadget untuk membocorkan memori
      Branch predictor race conditions masuk ke kernel ketika pembaruan branch predictor yang sudah dilatih masih diproses, sehingga pembaruan itu terhubung ke level privilege yang salah. Ini kemudian digunakan lagi untuk mengarahkan branch kernel ke disclosure gadget dan membocorkan memori

  • Kalau branch predictor CPU bisa langsung memakai informasi untuk memeriksa batas buffer dan level privilege kode, masalah seperti ini akan jauh lebih mudah dicegah
    Namun sepertinya itu tidak akan terjadi sampai void* direbut dari tangan dingin para programmer C dan pointer diperkaya dengan informasi penting

    • Saya tidak mengerti bagaimana itu bisa membantu. Ini masalah hardware, bukan abstraksi software, jadi mengubah “pointer” tidak akan berdampak apa pun pada transistor
      Untuk melakukan yang Anda inginkan, dibutuhkan arsitektur hardware tempat semua load/store harus melewati semacam “alamat yang diperkaya” yang menyimpan informasi batas
      Dengan kata lain, Anda pada dasarnya meminta segmentasi 80286, yang sudah pernah ada dan tidak memberikan apa yang diinginkan. Alasannya, segment descriptor itu pun harus dimuat dengan benar oleh software. Dari sudut pandang software, pada akhirnya itu tetap “sekadar pointer”, sehingga rentan terhadap kesalahan yang sama
    • Yang Anda inginkan adalah CHERI
    • Kita juga bisa memahami cakupan masalahnya dengan lebih baik. Adanya kerentanan tidak otomatis berarti menjadi serangan
      Dalam kasus speculative execution, untuk benar-benar memanfaatkan kerentanan itu dibutuhkan persiapan yang tidak masuk akal banyaknya. Hampir satu-satunya cara yang benar-benar bisa dipakai adalah ketika seseorang memiliki akses langsung ke komputer tersebut dan menjalankan kode level rendah. Bukan skenario seperti membocorkan rahasia arbitrer hanya dengan kode JS yang berjalan di browser
      Jika sebuah sistem cukup bernilai sehingga organisasi swasta khusus atau organisasi yang didukung negara mau melakukan riset dan penargetan yang diperlukan, sejak awal sistem itu seharusnya memiliki mekanisme yang mencegah eksekusi kode arbitrer tanpa izin
      Secara pribadi, peningkatan performanya benar-benar terasa, jadi saya mematikan semua mitigasi

  • Advisori keamanan Intel: https://www.intel.com/content/www/us/en/security-center/advi...

  • Penasaran apakah perangkat keras AMD juga memiliki celah serupa. Eksekusi spekulatif tampak seperti kerentanan yang sangat sulit ditambal di ruang prosesor bersama, jadi saya penasaran bagaimana AMD bisa menghindarinya

    • Menurut blog para peneliti, Branch Privilege Injection tidak memengaruhi CPU selain Intel
      Katanya tidak ditemukan masalah pada sistem AMD dan ARM yang dievaluasi
      Sumber: https://comsec.ethz.ch/research/microarch/branch-privilege-i...
    • Singkatnya, bukan berarti AMD “berhasil menghindarinya”. Kanal samping eksekusi spekulatif bukan satu kerentanan, melainkan satu keluarga kerentanan
      Kerentanan spesifik ini tampaknya khusus Intel seperti Meltdown, tetapi AMD juga memang rentan terhadap Spectre yang asli
    • Secara ketat, eksekusi spekulatif itu sendiri bukan kerentanan. Ini adalah mekanisme yang dibutuhkan semua CPU berkinerja tinggi modern, dan “modern” di sini kira-kira sejak pergantian abad
      Namun mesin eksekusi spekulatif itu kompleks, sehingga bug dan kerentanan sangat luas tersebar
      Kemungkinan besar AMD dan ARM juga memiliki bug serupa. Cukup pikirkan berapa lama bug seperti ini tidak ditemukan di Intel
      Sayangnya, solusi sebenarnya adalah mengakui bahwa kode yang berjalan di sistem modern tidak bisa diisolasi, dan ini bisa fatal bagi model bisnis sebagian perusahaan yang sangat kaya
    • Solusi untuk kerentanan spesifik ini tampak intuitif. Saat memasukkan pembaruan prediktor cabang ke antrean, simpan snapshot tingkat privilege saat ini, lalu bawa snapshot itu bersama pembaruan saat mengalir melalui buffer internal prosesor
      Bukankah ini solusi yang sama seperti masalah yang mungkin muncul di perangkat lunak?

  • Katanya, “Untuk menutup celah seperti ini diperlukan pembaruan khusus pada mikrokode prosesor. Ini bisa dilakukan melalui pembaruan BIOS atau sistem operasi, jadi seharusnya terpasang di PC melalui salah satu pembaruan kumulatif terbaru Windows,” tetapi kenapa hanya menyebut Windows? Bagaimana dengan pengguna Linux?

    • Intel mendistribusikan pembaruan mikrokode untuk Linux di sini: https://github.com/intel/Intel-Linux-Processor-Microcode-Dat...
      Distro dikonfigurasi untuk mengambilnya dari sana dan mendistribusikannya secara otomatis
      Namun saya tidak begitu tahu apa yang harus dicek untuk memastikan apakah mitigasi spesifik ini sudah masuk
    • Kernel Linux sudah lama mendukung pemuatan mikrokode (CONFIG_MICROCODE / CONFIG_MICROCODE_INTEL)
      Namun Intel harus merilis file mikrokode yang diperlukan agar para pengelola distro bisa memperbarui paketnya, lalu itu akan disertakan dalam pembaruan sistem

  • Penasaran apakah Intel punya cara untuk pulih. Mereka tidak punya produk yang meyakinkan di pasar, riset dan pengembangan butuh waktu lama, dan foundry mereka tertinggal dari pesaing sehingga terus menjadi sumber kerugian
    Selain itu, x86 makin terdesak oleh perangkat keras ARM, dan kini RISC-V dari Tiongkok juga makin besar. Tentu ada juga sudut pandang semikonduktor AS. Apalagi setelah masalah saat COVID, apakah AS akan membiarkan produsen kunci seperti Intel runtuh?

    • Intel tidak berada dalam krisis sebesar yang digembar-gemborkan blog-blog teknologi
      Situasinya memang tidak bagus, tetapi sensasionalismenya terasa konyol
      Gamer hanya beberapa persen dari pengguna produk Intel, tetapi justru cerita dari sisi itu yang paling sering terdengar. Satu atau dua pesanan pusat data saja lebih besar daripada seluruh CPU gaming yang dijual Intel dalam setahun. Intel masih bertahan dengan baik di pasar pusat data
      Selain itu, Intel juga masih mendominasi pasar laptop korporat, dan pasar ini juga jauh lebih besar daripada pasar gamer
    • Intel masih memiliki pangsa pasar x86 jauh di atas 70%. Landasan pacunya masih panjang
      Tahun lalu Arm hanya punya pangsa 15% di pasar pusat data, dan di pasar Windows juga belum membuat kemajuan besar
    • Sepertinya tergantung ekspektasi. Apakah mereka akan baik-baik saja sebagai perusahaan? Menurut saya ya. Apakah mereka akan setonjol pada berbagai titik dalam sejarahnya? Sepertinya tidak
      Terlepas dari produk, dari sudut pandang pemegang saham/bisnis saya mencoba memisahkannya karena kinerja keuangan belakangan makin kurang mencerminkan produk akhir, tetapi menurut saya Intel nyaris terlalu besar untuk gagal
    • Sepertinya saya pernah membaca bahwa perusahaan seperti Apple dan Nvidia ingin memakai foundry Intel; kalau memang inferior, kenapa mereka mau? Atau itu cerita yang berbeda?

  • Saya ingin memastikan apakah pemahaman saya benar: pada titik saat ini, apakah semua sistem operasi utama sudah merilis patch yang memitigasi masalah ini atau menerapkan mikrokode terkait?

    • Betul. Tanggal pencabutan embargo adalah 13 Mei, hari ini