Teknologi Zenbleed

 (lock.cmpxchg8b.com)
2 poin oleh GN⁺ 2023-07-25 | 1 komentar | Bagikan ke WhatsApp
  • Zenbleed adalah kerentanan yang memanfaatkan pemulihan vzeroupper yang salah prediksi pada keluarga AMD Zen 2, sehingga memungkinkan pembacaan data yang tersisa di file register vektor pada inti fisik yang sama
  • Terdaftar sebagai CVE-2023-20593, dan mencakup produk Zen 2 seperti Ryzen 3000/4000/5000 with Radeon Graphics/7020 with Radeon Graphics, Ryzen PRO, Threadripper 3000, dan EPYC “Rome”
  • Serangan ini terjadi ketika XMM Register Merge Optimization, register renaming, dan vzeroupper yang salah prediksi berlangsung berurutan dalam jendela waktu yang sempit, dan operasi dasar seperti strlen, memcpy, serta strcmp pun bisa menjadi sasaran pengamatan
  • Varian yang dioptimalkan dapat membocorkan sekitar 30KB per detik per inti, dan berbagi file register pada inti fisik yang sama menjadi masalah lintas batas VM, sandbox, container, dan proses
  • Disarankan menerapkan pembaruan mikrokode AMD, dan sebagai langkah sementara DE_CFG[9] chicken bit dapat diatur, tetapi bisa menimbulkan biaya performa, serta menonaktifkan SMT saja tidak cukup

Unit eksekusi yang menjadi sasaran Zenbleed

  • CPU x86-64 memiliki register vektor XMM 128-bit, dan CPU modern memperluasnya menjadi YMM 256-bit dan ZMM 512-bit
  • Register vektor digunakan bukan hanya untuk komputasi numerik, tetapi juga dalam fungsi pustaka C standar glibc seperti strcmp, memcpy, dan strlen
  • strlen yang dioptimalkan dengan AVX2 di glibc menggabungkan beberapa instruksi vektor untuk menemukan posisi byte nul pertama dalam string
    • vpxor xmm0,xmm0,xmm0 menjadikan bagian bawah ymm0 bernilai 0
    • vpcmpeqb ymm1,ymm0,[rdi] membandingkan byte string dengan byte 0
    • vpmovmskb eax,ymm1 memindahkan hasil perbandingan ke register umum
    • tzcnt eax,eax menghitung posisi byte nul pertama

vzeroupper dan file register

  • vzeroupper adalah instruksi yang menjadikan bit-bit atas register vektor bernilai 0
  • Jika register XMM dan YMM digunakan secara campuran, register XMM dipromosikan ke lebar penuh, dan dalam proses ini dapat muncul dependensi pada bit atas
  • glibc menggunakan vzeroupper agar hasil berikutnya tidak bergantung pada bit atas, sehingga stall yang tidak perlu dapat dihindari
  • CPU tidak menempatkan tiap register pada lokasi fisik yang tetap, melainkan mengelola alokasi register fisik melalui Register File dan Register Allocation Table
  • Saat menjadikan register XMM bernilai 0, CPU dapat menetapkan flag z-bit di RAT tanpa benar-benar menyimpan bit fisiknya
    • Flag ini dapat diterapkan secara independen pada bagian atas dan bawah register YMM
    • vzeroupper dapat menetapkan z-bit lalu melepaskan sumber daya terkait dari file register

Kerentanan yang muncul saat pemulihan eksekusi spekulatif

  • CPU modern menggunakan eksekusi spekulatif, sehingga operasi yang dijalankan pada cabang yang salah prediksi harus dibatalkan
  • Masalahnya adalah ketika vzeroupper yang salah prediksi telah dieksekusi lalu dipulihkan, mengembalikan hanya z-bit tidak cukup untuk memulihkan dengan benar status sumber daya file register yang sudah dilepas
  • Dengan penjadwalan yang presisi, beberapa prosesor dapat dibuat memulihkan vzeroupper yang salah prediksi secara tidak akurat
  • Teknik ini adalah CVE-2023-20593 dan memengaruhi seluruh keluarga Zen 2
    • AMD Ryzen 3000 Series Processors
    • AMD Ryzen PRO 3000 Series Processors
    • AMD Ryzen Threadripper 3000 Series Processors
    • AMD Ryzen 4000 Series Processors with Radeon Graphics
    • AMD Ryzen PRO 4000 Series Processors
    • AMD Ryzen 5000 Series Processors with Radeon Graphics
    • AMD Ryzen 7020 Series Processors with Radeon Graphics
    • AMD EPYC “Rome” Processors

Syarat serangan dan cakupan kebocoran

  • Untuk memicu bug ini, XMM Register Merge Optimization, register renaming, dan vzeroupper yang salah prediksi harus berlangsung berurutan dalam jendela waktu yang presisi
  • Contoh urutan instruksi menggunakan struktur berikut
    • vcvtsi2s{s,d} memicu merge optimization
    • vmovdqa memicu register renaming
    • Jika cabang kondisional sebenarnya taken tetapi CPU memprediksi jalur not-taken, vzeroupper dieksekusi secara salah prediksi dan bug terjadi
  • Karena operasi dasar seperti strlen, memcpy, dan strcmp juga menggunakan register vektor, operasi tersebut dapat menjadi sasaran pengamatan di mana pun dijalankan dalam sistem
  • Karena file register dibagikan pada inti fisik yang sama, VM, sandbox, container, dan proses lain juga termasuk dalam cakupan dampak
  • Dua hyperthread berbagi file register fisik yang sama
  • Varian serangan yang dioptimalkan dapat membocorkan sekitar 30KB per detik per inti, cukup cepat untuk memantau kunci kriptografi dan kata sandi pengguna yang sedang login
  • Advisori teknis dan kode terkait dipublikasikan di security research repository milik Google
  • Kode uji disediakan untuk Linux, tetapi bug ini tidak bergantung pada sistem operasi tertentu, sehingga semua sistem operasi terdampak

Metode penemuan: fuzzing CPU dan Oracle Serialization

  • Kerentanan ini ditemukan melalui fuzzing
  • Industri CPU juga melakukan validasi pascaproduksi silikon (Post-Silicon Validation) untuk menemukan cacat perangkat keras
  • Berbeda dari fuzzing berbasis coverage pada umumnya, CPU tidak memiliki metrik yang secara langsung berpadanan dengan code coverage
  • Sebagai gantinya, performance counters digunakan untuk memberi umpan balik kepada fuzzer tentang peristiwa arsitektural yang menarik
    • Dengan cara ini, urutan instruksi yang sulit ditemukan secara kebetulan dapat dieksplorasi
    • Fitur seperti merge optimization juga dapat ditemukan secara otomatis
  • Fuzzing perangkat lunak biasanya mencari crash, tetapi pada program CPU yang dihasilkan secara acak, crash itu sendiri bisa saja merupakan perilaku yang benar
  • Salah satu pendekatan sebelumnya, reversi, menghasilkan operasi kebalikan untuk tiap instruksi acak lalu memeriksa apakah keadaan akhir berbeda dari keadaan awal
    • Pada arsitektur CISC seperti x86, pembuatan test case menjadi lebih rumit
  • Metode lain adalah menggunakan oracle untuk membandingkan hasil CPU yang diuji dengan CPU lain atau simulator
  • Oracle Serialization menggabungkan kedua gagasan tersebut
    • Program acak dibuat lalu secara otomatis diubah ke bentuk yang diserialkan
    • Ditambahkan elemen serialisasi seperti store/load barrier, speculation fence, dan cache line flush
    • Program asli dan program yang diserialkan harus menghasilkan keluaran yang sama meskipun karakteristik performanya berbeda
  • Jika keadaan akhir tidak cocok, hal itu bisa menunjukkan kesalahan eksekusi mikroarsitektur, dan ketidakcocokan inilah yang mengarah pada penemuan Zenbleed

Respons dan keterbatasan deteksi

  • Kerentanan ini dilaporkan ke AMD pada 15 Mei 2023
  • AMD mendistribusikan pembaruan mikrokode untuk prosesor yang terdampak
  • Vendor BIOS atau sistem operasi mungkin sudah menyediakan patch yang mencakup pembaruan tersebut
  • Respons yang direkomendasikan adalah menerapkan pembaruan mikrokode
  • Jika pembaruan tidak dapat diterapkan, solusi sementara berbasis perangkat lunak adalah mengatur DE_CFG[9] chicken bit
    • Bisa menimbulkan biaya performa
    • Di Linux, pengaturan dapat dilakukan pada semua inti dengan msr-tools
    • Di FreeBSD, gunakan cpucontrol(8)
    • Jika tidak mengetahui cara mengatur MSR pada sistem operasi lain, diperlukan dukungan vendor
  • Menonaktifkan SMT saja tidak cukup
  • Belum ada teknik deteksi serangan yang andal yang diketahui
    • Karena tidak memerlukan system call atau hak istimewa khusus
    • Juga tidak memungkinkan mendeteksi secara statis penggunaan vzeroupper yang tidak semestinya

Bacaan terkait

1 komentar

 
GN⁺ 2023-07-25
Komentar Hacker News

  • Ini benar-benar keren, dan bisa menjadi contoh klasik bahwa menjalankannya di VM tidak berarti aman
    VM escape memang sudah lama diketahui, tetapi yang ini adalah kerentanan berskala besar dengan eksekusi yang sederhana dan imbal hasil besar bahkan tanpa escape
    Fakta bahwa bug ini diperbaiki lewat microcode tidak berarti tidak ada bug serupa lainnya. Banyak 0-day sering kali sudah diketahui oleh blackhat bayaran jauh sebelum dipublikasikan
    Kerentanan CPU yang ditemukan dalam beberapa tahun terakhir:
    https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)
    https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)
    https://aepicleak.com/
    https://en.wikipedia.org/wiki/Software_Guard_Extensions#SGAxe
    https://en.wikipedia.org/wiki/Software_Guard_Extensions#LVI
    https://en.wikipedia.org/wiki/Software_Guard_Extensions#Plundervolt
    https://en.wikipedia.org/wiki/Software_Guard_Extensions/…
    https://en.wikipedia.org/wiki/Software_Guard_Extensions#Enclave_attack
    https://en.wikipedia.org/wiki/Software_Guard_Extensions/…
    https://www.vusec.net/projects/crosstalk/
    https://en.wikipedia.org/wiki/Hertzbleed
    https://securityweek.com/amd-processors-expose-sensitive-data-new-squi…

    • Masalahnya adalah VM tidak lagi benar-benar merupakan mesin virtual
      Alih-alih menafsirkan instruksi dengan pernyataan switch besar, instruksi dijalankan di CPU sungguhan dan bergantung pada beberapa flag perangkat keras yang menjamin data atau instruksi tidak saling tumpang tindih. CPU memang berjanji demikian, tetapi dalam kenyataannya janji seperti itu sulit ditepati
    • Perbandingan dengan Meltdown/Spectre bisa sedikit menyesatkan
      Pada kasus itu CPU melakukan persis apa yang seharusnya dilakukan, tetapi memungkinkan bentuk serangan yang benar-benar baru berbasis timing; sementara Zenbleed kali ini lebih mirip bug tradisional, di mana data yang seharusnya tidak ada malah tertinggal di register
    • Menjalankan kode yang tidak tepercaya di sandbox, container, atau VM setidaknya sudah tidak aman sejak Rowhammer
      Banyak kerentanan seperti ini menurut saya muncul karena pihak software dan pihak hardware tidak benar-benar saling berbicara dengan baik. Pihak software membuat asumsi soal jaminan isolasi, sementara pihak hardware tidak cukup memberi peringatan ketika asumsi seperti itu mungkin muncul
    • Pada akhirnya rasanya sebagian besar hal seperti ini memang berkaitan dengan prediksi cabang
      Prediksi cabang terasa secara inheren terlalu kompleks sehingga mau tidak mau selalu terekspos pada kerentanan seperti ini, atau begitu berbeda dari cara intuitif kita memahami jalur kode dan eksekusi instruksi sehingga sulit membayangkan kondisi batas sebelum semuanya terlambat
      Apakah kompleksitas arsitektur CPU pada titik tertentu akan menjadi terlalu sulit untuk dipahami, sehingga kita rela menerima penurunan performa demi menjaganya tetap lebih sederhana?
    • Saya pernah melihat beberapa perusahaan mencampur VM yang terekspos ke internet/DMZ dan VM internal di hypervisor yang sama
      Saya pernah menyoroti ini dan menyarankan agar dipisahkan dengan hypervisor terpisah sebagai air gap, tetapi selalu diabaikan. Pada akhirnya itu mungkin akan menjadi kerugian mereka sendiri

  • README dalam file tar exploit berisi detail lebih lanjut dan jadwal pengungkapan
    2023-05-09 Salah satu komponen dalam pipeline validasi CPU menghasilkan hasil yang tidak normal
    2023-05-12 Masalah berhasil diisolasi dan direproduksi, investigasi berlanjut
    2023-05-14 Cakupan dan tingkat keparahan masalah dipahami
    2023-05-15 Laporan status singkat ditulis dan dibagikan ke AMD PSIRT
    2023-05-17 AMD mengonfirmasi laporan dan mengakui bahwa masalah ini dapat direproduksi
    2023-05-17 Pengembangan PoC yang andal selesai dan dibagikan ke AMD
    2023-05-19 Mulai memberi tahu vendor kernel dan hypervisor utama
    2023-05-23 Menerima pembaruan mikrokode beta untuk Rome dari AMD
    2023-05-24 Mengonfirmasi bahwa pembaruan tersebut memperbaiki masalah dan memberi tahu AMD
    2023-05-30 AMD memberi tahu bahwa mereka telah mengirim pemberitahuan keamanan ke para mitra
    2023-06-12 Meeting dengan AMD untuk membahas status dan detail
    2023-07-20 AMD merilis patch lebih awal dari tanggal embargo yang telah disepakati tanpa pemberitahuan
    2023-07-21 Karena perbaikannya sudah dipublikasikan, diusulkan agar distro utama diberi tahu secara pribadi untuk menyiapkan pembaruan paket firmware
    2023-07-24 Pengungkapan publik

  • Ini benar-benar menakutkan. Di perangkat Zen 2 saya, Ryzen 3600, saya menjalankan exploit sebagai pengguna tanpa hak istimewa, lalu menyalin dan menempelkan sebuah string ke editor teks di latar belakang (Kate), dan dalam beberapa detik potongan string itu tercatat di output zenbleed
    Untungnya exploit ini tampaknya sangat bergantung pada rutinitas assembly tertentu, jadi akan sangat sulit dieksploitasi dari JS atau WASM di browser. Kalau tidak, kebocoran akan sangat mudah terjadi hanya dengan membiarkan tab berbahaya terbuka di latar belakang selama beberapa jam
    Sedang menunggu maintainer Fedora mendistribusikan mikrokode baru agar kernel bisa memperbaruinya saat proses boot

    • Setidaknya satu orang di sini mengatakan bahwa ini juga bisa direproduksi dengan JavaScript: https://news.ycombinator.com/item?id=36849767
    • Saya juga mencobanya di perangkat Zen 2 saya, dan serangan yang sama tetap bekerja bahkan saat dijalankan di dalam KVM
    • Jika nanti ditemukan cara di JS, tampaknya ini bisa berlaku cukup luas
      Pada saat yang sama saya berharap patch perangkat lunak di V8 dan SpiderMonkey bisa datang lebih awal dan memberi mitigasi tambahan
      Namun exploit JS juga akan membutuhkan cara untuk mengekfiltrasi data ke luar, dan tampaknya cukup sulit untuk menyembunyikan itu sepenuhnya
    • Saya tidak tahu bagaimana cara membangun PoC. Di Ubuntu saya mendapat "No such file or directory" dan error 127

  • Terasa seperti bukan kebetulan bahwa OpenBSD menambahkan pemrosesan mikrokode AMD dalam 3 hari terakhir
    https://news.ycombinator.com/item?id=36838511

  • Sepertinya pernyataan bahwa AMD telah merilis pembaruan mikrokode untuk prosesor yang terdampak kurang tepat
    AMD telah merilis pembaruan mikrokode[0] untuk family 17h model 0x31 dan 0xa0, dan menurut WikiChip[1] ini mengacu pada Rome, Castle Peak, dan Mendocino
    Sejauh ini, tampaknya belum ada pembaruan mikrokode untuk Renoir, Grey Hawk, Lucienne, Matisse, dan Van Gogh. Untungnya, kernel baru dapat sekadar mengatur chicken bit untuk semuanya, dan memang melakukan itu[2]
    [0] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...
    [1] https://en.wikichip.org/wiki/amd/cpuid#Family_23_.2817h.29
    [2] https://github.com/torvalds/linux/commit/522b1d69219d8f08317...

  • Jika melihat bagian terkait, teknik ini adalah CVE-2023-20593 dan bekerja pada semua prosesor kelas Zen 2, setidaknya termasuk produk berikut
    AMD Ryzen 3000 Series Processors
    AMD Ryzen PRO 3000 Series Processors
    AMD Ryzen Threadripper 3000 Series Processors
    AMD Ryzen 4000 Series Processors with Radeon Graphics
    AMD Ryzen PRO 4000 Series Processors
    AMD Ryzen 5000 Series Processors with Radeon Graphics
    AMD Ryzen 7020 Series Processors with Radeon Graphics
    AMD EPYC “Rome” Processors

    • Saya penasaran apakah ini berarti “baru dikonfirmasi pada Zen 2”, atau memang berarti masalah ini dipastikan hanya terbatas pada arsitektur tersebut
      Mungkin teknik yang sama atau serupa juga bisa bekerja pada core Zen/Zen+ yang lebih awal atau Zen 3 yang lebih baru, tetapi belum berhasil dibuktikan?
    • 2700X saya tampaknya lolos tipis. Dengan asumsi seri 7020 terdampak dan seri 7000 tidak, begitu kesimpulannya
    • Saya penasaran bagaimana dengan PlayStation 5. Hal yang sama juga berlaku untuk Xbox dan perangkat dari Valve itu
    • Apakah Ryzen 5000 tanpa Radeon memang tidak rentan? Prosesor tersebut tampaknya Zen 3
      AMD Ryzen 9 5950x Desktop Processor saya juga terlihat sebagai Zen 3, jadi sepertinya aman
      Saya memang tidak menjalankan beban kerja yang tidak tepercaya, tetapi lebih baik siap sedia daripada menyesal
    • Sebagai catatan, Ryzen 3000 APU bukan Zen 2

  • Situsnya sedang tumbang karena trafik: https://web.archive.org/web/20230724143835/https://lock.cmpx...

    • Ini cuma halaman HTML statis sederhana, jadi saya tidak paham bagaimana mungkin di tahun 2023 situs statis bisa tumbang karena trafik
      Dalam kebanyakan kasus, trafik HN bahkan hampir tidak mencapai 100 pageview per detik
    • Tautan yang lebih cepat: https://archive.is/QAwvQ
    • Yang asli pada akhirnya tetap bisa dimuat. Mungkin tergantung lingkungan

  • https://www.amd.com/en/resources/product-security/bulletin/a...
    Menurut pengumuman keamanan AMD, pembaruan firmware untuk CPU non-EPYC tidak akan keluar sampai akhir tahun. Sampai saat itu, apakah pengguna harus mematikan chicken bit dan menerima penurunan performa?

    • Apakah AMD masih waras? Ini bukan masalah tingkat keparahan sedang

  • Keren sekaligus menakutkan. Saya menjalankan sampel 10MB selama 1 menit, dan bisa “membocorkan” sebagian kata sandi Bitwarden saya, kata sandi login ssh, serta potongan kredensial bank, dan semuanya mudah direkonstruksi

  • Tulisannya benar-benar bagus. Saya terutama menyukai bagian yang membahas bagaimana kita bisa menilai apakah program pembangkit acak berjalan dengan benar.
    Pendekatan yang paling jelas adalah menjalankannya pada oracle seperti prosesor lain atau simulator untuk melihat apakah ia berperilaku dengan cara yang sama.
    Namun, untuk memeriksa efek mikroarsitektur dalam jendela timing yang sempit, kita juga bisa menulis program yang sama dengan menyisipkan berbagai stall, fence, nop, dan sebagainya. Pada kode single-thread, hal itu seharusnya tidak memengaruhi output, tetapi di dalam CPU, secara mikroarsitektur ia akan melakukan hal yang cukup berbeda. Dengan begitu, CPU bisa menjadi oracle bagi dirinya sendiri.

    • Bagian ini benar-benar menarik, dan saya terutama menyukai perbedaan antara software fuzzing dan hardware fuzzing.
      Saya juga suka chicken bit.