Leaking Data on Intel CPUs via Cache Evictions

CacheOut: Leaking Data on Intel CPUs via Cache Evictions

Halo, semuanya, saya Stephan, dan saya akan berbicara tentang: “CacheOut: Membocorkan Data pada CPU Intel melalui Penggusuran Cache.” Tetapi sebelum saya melakukannya, mari kita bahas beberapa latar belakang terlebih dahulu. Mari kita ambil sistem tradisional dari sekitar dua puluh hingga tiga puluh tahun yang lalu. Anda akan menemukan bahwa ia memiliki CPU dengan sedikit register yang cepat untuk diakses, memori utama yang besar yang lebih lambat untuk diakses, dan akhirnya penyimpanan disk yang bisa sangat besar, tetapi sangat lambat untuk diakses. Dan tren umum yang telah kita lihat adalah bahwa CPU benar-benar maju dengan kecepatan yang jauh lebih cepat daripada memori utama dan penyimpanan disk Anda.

Dan ini sebenarnya menyebabkan peningkatan kesenjangan kinerja yang Anda lihat di sini.

Jadi, bagaimana kita mengatasi itu? Yah, kami memiliki hierarki cache yang menyimpan salinan data dekat dengan CPU. Jadi kami memiliki cache level satu, yang kecil dan cepat. Kami memiliki cache level dua yang sedikit lebih besar, tetapi sedikit lebih lambat untuk diakses.

Dan akhirnya, kami memiliki cache level tiga yang bisa sangat besar, tetapi juga cukup lambat untuk diakses, tetapi masih lebih cepat dari memori utama Anda. Jadi yang perlu diingat: cache lebih cepat diakses, tetapi ukurannya juga lebih kecil. Sekarang setelah kita memahami cache, mari kita lihat apa yang terjadi di tahun 2018. Anda mungkin pernah melihat salah satu dari ketiga logo ini, karena ini adalah logo Meltdown, Spectre, dan Foreshadow. Dan pada tahun 2018, dua kelas serangan terungkap, yaitu: serangan eksekusi spekulatif dan sementara.

Jadi mari kita ambil hierarki cache dasar kita lagi, dan perkenalkan inti eksekusi. Salah satu properti penting untuk dibicarakan adalah bahwa cache sebenarnya dibagi di antara domain keamanan. Jadi jika kita memiliki sistem operasi Linux atau firmware UEFI, mungkin hypervisor dan mesin virtual, semua ini berbagi cache L1d.

Dan untuk mengisolasi aplikasi tersebut satu sama lain dengan benar, inti akan mencegah aplikasi melintasi domain keamanan. Jadi, jika kami memiliki sistem operasi kami di sini dan kami memiliki aplikasi jahat, dan mencoba membaca sesuatu dari sistem operasi.

Apa yang akan terjadi adalah bahwa inti eksekusi akan membatalkan operasi itu dan menyebabkan kesalahan. Dan karena itu, kami juga menyebut operasi ini sebagai beban yang salah.

Apa yang ditunjukkan Meltdown adalah bahwa sebenarnya ada cukup waktu bagi penyerang untuk membocorkan data itu. Jadi, kami memiliki sistem operasi kami di sini, dan dalam hal ini, sistem operasi memiliki beberapa data yang disimpan dalam cache L1d. Dan sekarang, penyerang jahat dapat dengan mudah menggunakan beban yang salah untuk benar-benar membaca data tersebut dari cache L1d dan kemudian menggunakan serangan saluran samping untuk menyedot data tersebut.

Dan ini semua bisa terjadi sebelum inti eksekusi membatalkan beban yang salah dan benar-benar menyebabkan kesalahan. Jadi ini sebenarnya adalah kerentanan perangkat keras yang memengaruhi banyak generasi CPU Intel.

Dan karena itu diliput di seluruh berita, itu memiliki dampak publik yang besar dan ini mendorong upaya mitigasi yang luas. Bahkan, jika Anda membeli CPU Intel modern saat ini, Anda akan menemukan bahwa tidak mungkin lagi bocor dari cache. Begitulah tahun 2018.

Apa yang terjadi pada tahun 2019 adalah kelas serangan baru terungkap, yaitu: Serangan Pengambilan Sampel Data Mikro, atau disingkat MDS. Jadi ternyata buffernya lebih banyak. Anda memiliki buffer pengisian, buffer toko, dan port beban. Dan sekali lagi, semua ini sebenarnya dibagi di antara domain keamanan yang berbeda. Jadi, kami memiliki sistem operasi kami, kami memiliki firmware UEFI kami, kami bahkan memiliki hypervisor dan mesin virtual, dan semua ini berbagi buffer ini.

Jadi apa yang dilakukan MDS, sebenarnya menargetkan buffer CPU internal ini. Dan untuk memahami cara melakukannya, pada dasarnya kita melihat cara kerjanya. Jadi pada dasarnya dengan MDS, Anda dapat, mirip dengan Meltdown, menggunakan beban yang salah atau bantuan untuk mengakses data orang lain yang ada di buffer CPU pada dasarnya.

Dan cara Anda melakukannya, pada dasarnya adalah dengan mereferensikan pointer NULL di bawah spekulasi. Dan ini benar-benar berfungsi di seluruh proses, VM, dan Intel SGX.

Itu juga cukup parah, jadi itu juga ada di seluruh berita. Faktanya, itu memiliki konsekuensi yang sangat mirip dengan Meltdown. Oleh karena itu, mengapa kadang-kadang dijuluki Meltdown kedua. Jadi MDS sebenarnya mengambil sampel data yang melewati buffer. Artinya jika korban berjalan pada inti eksekusi, dan melakukan beban, itu akan mengambil data dari cache L2.

Dan di sini, penyerang dapat menggunakan beban yang salah untuk mengekstrak data dari buffer pengisian, dan kemudian menyedotnya menggunakan serangan saluran samping. Saat data berlanjut ke beban yang sedang dieksekusi pada inti eksekusi. Ini juga berarti bahwa dengan MDS, Anda hanya mengambil sampel apa pun yang lewat pada suatu waktu. Jadi jika kita memiliki titik oranye, Anda hanya akan melihat titik oranye dari buffer pengisi. Dan jika kita memiliki titik biru di sini, maka Anda hanya akan melihat titik biru dari buffer pengisi.

Baca Juga :  Liquid Metal Maintenance for 8th Gen Intel Processors. Delid Check

Dan akhirnya, jika kita memiliki titik hijau ini, Anda hanya akan melihat titik hijau dari buffer pengisi.

Ini hanya berarti bahwa apa pun yang lewat pada saat itu, itulah yang sebenarnya akan Anda ekstrak menggunakan MDS. Dan itu benar-benar seperti minum dari selang kebakaran. Karena Anda sebenarnya hanya mendapatkan data apa pun yang ada dalam penerbangan. Dan ini juga berarti bahwa Anda sebenarnya tidak memiliki kendali atas apa yang sebenarnya Anda dapatkan.

Dan karenanya namanya: “Pengambilan Sampel Data Mikroarsitektur.” Karena Pengambilan Sampel Data Mikroarsitektur berarti Anda hanya mengambil sampel data dari buffer mikroarsitektur ini. Jadi bagaimana Intel memitigasi MDS? Jadi masalahnya adalah jika Anda mengganti proses, beberapa data mungkin tertinggal di buffer ini. Jadi idealnya Anda akan memperbaiki kebocoran itu sendiri, sehingga Anda tidak dapat lagi melakukan serangan MDS, tetapi pelanggan Anda sudah memiliki perangkat keras yang rentan, jadi bagaimana Anda akan menambal CPU tersebut?

Jadi Intel merilis pembaruan mikrokode yang pada dasarnya menambal instruksi verw untuk menyiram buffer CPU internal ini.

Dan sekarang ketika kita beralih di antara proses, sistem operasi akan mengeluarkan instruksi itu untuk menghapus buffer tersebut, sehingga data tidak lagi tersedia untuk penyerang. Dan ini membawa kita ke serangan CacheOut. Jadi, mari kita lihat lebih dekat mitigasi untuk MDS. Mitigasinya adalah menyiram buffer CPU internal, tetapi ini tidak benar-benar memperbaiki akar penyebab di balik MDS!

Anda masih dapat membocorkan data dari buffer tersebut, sebenarnya. Anda hanya perlu menemukan cara untuk mendapatkan data di dalam buffer tersebut. Dan ini membawa kita ke pertanyaan yang sangat penting. Apakah penanggulangan ad-hoc seperti buffer pembilasan cukup sebagai mitigasi? Dan sebagai bonus: bisakah kita mendapatkan kontrol lebih, sehingga kita tidak seperti gadis di sini yang minum dari selang kebakaran, tetapi lebih seperti kucing yang minum dari aliran air yang stabil.

Jadi, mari kita lihat beberapa pengamatan. Makalah RIDL menyebutkan bahwa: “Mengusir baris cache sebelumnya dari cache L1d… .

..prosesor harus menulisnya kembali melalui hierarki memori dan akan melakukannya melalui buffer pengisian baris. Jadi, apa artinya ini sebenarnya yang mengeluarkan cache memaksa data masuk ke buffer pengisian. Dan ZombieLoad bahkan melaporkan kebocoran 0,1 byte per detik meskipun ada mitigasi ini.

Dan kebocoran sisa ini sebenarnya mengkhawatirkan. Jadi apa yang kami harapkan adalah, jika kami mengambil diagram kami di sini, apakah ada adalah jalur oranye untuk pengusiran dari cache L1d ke cache L2. Dan yang kami temukan dengan CacheOut, sebenarnya ada jalur data untuk penggusuran yang melewati buffer pengisian baris. Dan perlu diingat, buffer pengisian baris masih bocor. Jadi jika kita benar-benar bisa mendapatkan beberapa data di sana, kita sebenarnya bisa membocorkannya.

Jadi, sebagai contoh: Katakanlah kita memiliki beberapa data di cache L1d, jika kita entah bagaimana bisa mengeluarkannya ke buffer pengisi, maka kita sebenarnya dapat menggunakan beban yang salah untuk membocorkannya, dan kemudian menyedotnya menggunakan serangan saluran samping, saat ia melanjutkan perjalanannya ke cache L2.

Jadi bagaimana kita bisa benar-benar memanfaatkan jalur data baru ini? Jadi CacheOut menargetkan data saat istirahat, dan pada dasarnya saya akan menunjukkan kepada Anda dalam diagram ini apa yang saya maksud dengan itu. Jadi, kami memiliki korban di sini yang menjalankan inti eksekusi, dan korban memuat sesuatu dari cache L2 dan melewati buffer pengisian, dan yang sebenarnya terjadi adalah salinan juga disimpan di cache L1d. Saat melanjutkan ke beban yang dilakukan oleh inti eksekusi.

Sekarang, sistem operasi berjalan dan mengeluarkan instruksi verw untuk menghapus buffer di sana. Jadi penyerang tidak bisa lagi mengekstrak data dari buffer tersebut. Dan sekarang sistem operasi pada dasarnya dapat menunggu sebentar dan ini benar-benar untuk menunjukkan bahwa Anda dapat menargetkan data saat istirahat. Dan sekarang penyerang lari. Dan penyerang sekarang akan memuat datanya sendiri ke dalam cache untuk mengisinya, dan pada dasarnya memastikan bahwa tidak ada ruang tersisa untuk data korban.

Dan dengan melakukan ini, pada dasarnya akan mengeluarkan data ke buffer pengisian, di mana ia kemudian dapat menggunakan beban yang salah untuk membocorkan data tersebut, saat sedang diusir ke cache L2.

Jadi untuk membandingkan ini: MDS menargetkan data dalam penerbangan. Jadi, kami memiliki inti eksekusi kami yang melakukan beban, ia mengambil data dari cache L2 dan saat berada di buffer pengisian, penyerang memiliki kesempatan untuk membaca data itu dari buffer pengisian. Dan kemudian hanya melanjutkan ke instruksi beban yang sedang dilakukan pada inti eksekusi. Jadi apa sajakah properti yang kami temukan untuk CacheOut?

Baca Juga :  Intel i5-10600K vs AMD Ryzen 5 3600 CPU Comparison

Kami benar-benar menemukan bahwa CacheOut dapat membocorkan data pada 2,85 KiB/s.

Dan karena kami menargetkan data di cache L1d, kami sebenarnya dapat menargetkan data yang tidak aktif. Dan berkat penggusuran, kami juga dapat memilih data apa yang ingin kami bocorkan secara khusus. Dan akhirnya, kami berhasil mengalahkan mitigasi yang diterapkan untuk MDS. Bahkan, kami mengeksploitasinya untuk meningkatkan CacheOut.

Bagaimana kami melakukannya? Nah, kami menemukan bahwa jika kami menyiram buffer sebelum memulai CacheOut, Anda sebenarnya dapat menggunakannya untuk meningkatkan sinyal. Jadi, kami menduga ini pada dasarnya karena Anda menghapus data yang tidak terkait dari buffer.

Terima kasih, Intel! Kami sebenarnya memiliki instruksi yang melakukan itu, itu adalah verw.

Jadi kami benar-benar berhasil menggunakan tindakan balasan mereka terhadap mereka. Dan CacheOut juga membuat berita besar, dan untuk menunjukkan alasannya, kita sebenarnya harus melihat apa yang bisa kita serang menggunakan CacheOut. Jadi, kami memiliki penyerang di ruang pengguna, apa yang sebenarnya bisa kami serang? Kami sebenarnya berhasil membocorkan kunci AES dan RSA. Kami dapat membocorkan bobot jaringan saraf di seluruh proses.

Dan, kita bahkan dapat menargetkan KASLR dan kernel stack canaries dari sistem operasi. Dan semua ini bekerja di seluruh mesin virtual, dan Anda bahkan dapat menargetkan hypervisor. Sebenarnya, ada sedikit sisa di CPU yang tidak bisa kita bocorkan. Faktanya, satu-satunya hal yang tidak saya sebutkan adalah Intel SGX. Jadi, bisakah kita menggunakan CacheOut untuk mengeksploitasi Intel SGX?

Jadi apa itu Intel SGX? Intel SGX adalah singkatan dari Software Guard eXtensions, dan memungkinkan pengembang untuk mempartisi kode mereka ke dalam enklave yang tidak dapat dibaca oleh siapa pun, seperti tidak dapat dibaca oleh aplikasi atau sistem operasi. Satu-satunya komponen yang benar-benar terpercaya adalah prosesornya. Dan untuk menjamin bahwa semua ini terjadi, bahwa enklave Anda benar-benar berjalan pada sistem asli yang tanpa kompromi dan sepenuhnya mutakhir, enklave Anda juga memiliki fitur yang disebut pengesahan jarak jauh.

Dan jika Anda lulus pengesahan jarak jauh, Anda tahu pasti bahwa Anda menjalankan perangkat keras Intel asli.

Jadi, satu hal yang kami putuskan untuk dilakukan, adalah melihat apakah kami dapat membuang memori dari enklave SGX menggunakan CacheOut. Jadi untuk contoh ini, kami benar-benar menempatkan gambar Mona Lisa di dalam kantong SGX. Dan kemudian kami hanya menggunakan CacheOut untuk mengekstrak Mona Lisa dari enclave. Dan, pada kenyataannya, seperti yang Anda lihat di sini, kami cukup berhasil melakukannya, yang berarti bahwa kami cukup berhasil membuang seluruh enklave SGX. Jadi, bisakah kita melakukan lebih baik dari itu?

Nah, itulah mengapa kami ingin menyerang proses pengesahan jarak jauh. Jadi, apa itu pengesahan jarak jauh? Saya katakan sebelumnya bahwa pada dasarnya membuktikan bahwa enklave berjalan pada perangkat keras Intel asli.

Bagaimana cara kerjanya? Nah, enklave pengguna menghasilkan laporan, yang diteruskan ke CPU, dan CPU kemudian menggunakan kunci pengesahan untuk menandatanganinya.

Dan sekarang, ini menghasilkan kutipan yang dikirim kembali ke enklave pengguna, yang kemudian dapat dikirim ke klien jarak jauh, pada dasarnya pengembang enklave, dan pengembang enklave kemudian dapat menggunakan Layanan Pengesahan Intel untuk memverifikasi bahwa enklave itu memang berjalan pada perangkat keras Intel asli. Artinya, semua kepercayaan didasarkan pada kunci pengesahan tunggal ini, yang Anda lihat di sini. Dan, sebenarnya, kami menggunakan CacheOut untuk membocorkan kunci itu. Jadi dengan kunci pengesahan di tangan kami, kami hanya dapat membuat dan menandatangani kutipan kami sendiri, dan Intel tidak dapat benar-benar mengetahui siapa yang menandatangani kutipan itu, hanya karena Enhanced Privacy ID, atau EPID, yang memastikan nama samaran.

Pada dasarnya, jika Anda memiliki kutipan, tanda tangan tidak dapat ditautkan kembali ke instance CPU tertentu yang menandatanganinya.

Itu hanya dapat ditautkan kembali ke seluruh kelompok CPU. Dan ini berarti privasi peretas Anda dijamin. Ini juga berarti bahwa satu kunci yang dikompromikan mengikis kepercayaan di seluruh ekosistem SGX. Dan itu juga berarti bahwa, sebagai seorang peretas, pada dasarnya Anda tidak lagi membutuhkan mesin SGX yang sebenarnya untuk menandatangani tanda kutip, karena dengan kunci di tangan Anda, Anda juga dapat melakukannya di mesin AMD atau Arm. Jadi, kami berpikir sedikit tentang ini.

Dan kami menerapkan Pengesahan sebagai Layanan. Jadi kami menerapkan bot Twitter, yang pada dasarnya menandatangani tweet Anda seperti kutipan, dan dengan mentalitas: “Jika Anda men-tweet, kami akan menandatanganinya.” Dan itu benar-benar menandatangani 100+ kutipan dalam waktu dua jam, sampai diblokir oleh Github.

Dan, sementara kami merilis makalah kami, Intel juga merilis tindakan pencegahan. Tetapi kami menemukan bahwa bahkan sebulan setelah itu terjadi, kuncinya masih dipercaya.

Dan alasan sederhananya adalah karena untuk mengembalikan kerahasiaan di SGX, pada dasarnya Anda harus menginstal pembaruan BIOS untuk mengembalikan kepercayaan. Dan ini bisa memakan waktu. Jadi Intel sebenarnya menyisakan waktu satu bulan bagi pengguna untuk melakukan itu. Jadi satu-satunya cara untuk mencegah penyalahgunaan bot Twitter kami, adalah dengan melakukan hardcode pada bidang MRSIGNER dan MRENCLAVE kami. Jadi seperti yang Anda lihat di sini, kami memiliki: “Ketika kantong yang baik menjadi buruk.

Baca Juga :  Apple Silicon ARM Chips vs Intel x86 Processors for Mac?

” Jika Anda memercayainya, saya pikir Anda memiliki masalah yang lebih buruk untuk dipecahkan sebagai pengembang enklave. Jadi untuk meringkas: Apa yang kami temukan adalah jalur data baru untuk pengusiran dari cache, yang melewati buffer pengisian baris. Dan kami telah mengeksploitasi jalur ini di CacheOut, pada dasarnya membocorkan data saat istirahat, dengan kemampuan untuk memilih data, dan dengan tingkat kebocoran 2,85 KiB/s.

Dan kami juga menunjukkan bahwa kami benar-benar dapat melewati mitigasi verw. Dan kami dapat menggunakan ini untuk membocorkan data di seluruh proses, VM, dan bahkan Intel SGX.

Tetapi yang lebih penting, apa yang kami tunjukkan adalah bahwa CacheOut melanggar kerahasiaan SGX. Ini pada dasarnya memungkinkan penyerang untuk menyamar sebagai kantong SGX yang sah. Jadi bagaimana Anda memperbaikinya? Nah, ada pembaruan mikrokode yang tersedia sejak 20 Juni. Jadi tambal mesin Anda, dan pastikan Anda tidak mempercayai kunci apa pun yang telah dikeluarkan sebelumnya.

Jadi itulah pembicaraan kami tentang: “CacheOut: Membocorkan Data pada CPU Intel melalui Penggusuran Cache.” Jika Anda ingin informasi lebih lanjut, Anda dapat mengunjungi situs web kami: https://cacheoutattack.com. Anda dapat menghubungi saya di Twitter. Dan dengan itu, saya berterima kasih atas waktu Anda, dan saya akan dengan senang hati menjawab pertanyaan apa pun.