bisakah kerentanan keamanan momok berada dalam mesin virtual?

Apakah mungkin mesin virtual seperti VirtualBox memiliki "momok" kerentanan keamanan? Saya pikir VM mungkin melakukan eksekusi out-of-order, tetapi menurut saya tidak mungkin mengintip cache untuk membaca hasilnya.

Apakah ada penjelasan bagaimana mungkin untuk membaca cache dari cpu virtual?

Ya, Sebuah penelitian kecil akan mengonfirmasi VMWare telah merilis tambalan untuk mengatasi Specter dan Meltdown. OS tamu harus ditambal, sebagai tambahan, ke hypervisor aktual (kedua tipe)

— Ramhound

Tergantung pada tingkat virtualisasi, kataku. Jika Anda mensimulasikan CPU virtual, maka Anda mungkin aman. Tapi bukan itu yang dilakukan VM modern.

— Bergi

Apakah ada penjelasan bagaimana mungkin untuk membaca cache dari cpu virtual?

Rincian @jms ada di pos kanonik yang saya tautkan dalam jawaban saya:

Spectre works on a different level ... In this attack, the attacker tricks the speculative execution to predictively execute instructions erroneously. In a nutshell, the predictor is coerced to predict a specific branch result that results in asking for an out-of-bound memory access that the victim process would not normally have requested resulting in incorrect speculative execution. Then by the side-channel, retrieves the value of this memory. In this way memory belonging to the victim process is leaked to the malicious process.

— Mokubai

@jms Virtualisasi hanya cepat karena menggunakan CPU fisik dengan abstraksi sesedikit mungkin dan bergantung pada perangkat keras CPU untuk memberikan isolasi dan abstraksi. Hal-hal seperti qemudapat melakukan emulasi yang akan lebih aman karena bukan CPU perangkat keras , tetapi jauh lebih lambat dan berbeda dari virtualisasi.

— Mokubai

Ya Specter dapat melewati batasan host / guest, guest / host dan guest / guest karena ini adalah tingkat level CPU yang berarti bahwa informasi yang berpotensi sensitif dapat bocor di apa pun yang berjalan pada inti CPU.

Sebagian besar berita di internet berbicara tentang penyedia cloud yang paling terpukul oleh ini karena mereka memiliki kelompok besar sistem yang tervirtualisasi dan berpotensi disalahgunakan untuk membocorkan informasi sensitif.

Sebagian besar penyedia besar seharusnya sudah ditambal terhadap kekurangan sekarang, sebaik mungkin, tetapi ini akan menjadi masalah yang tinggal bersama kami untuk beberapa waktu.

Security.SE memiliki T&J kanonik mengenai ini dan menyebutkan VM:

Saya menjalankan Mesin / Kontainer Virtual, sejauh mana saya rentan?

Sesuai jawaban Steffen Ullrich

Serangan krisis tidak melintasi VM, hanya kebocoran memori kernel ke proses lokal.

Spectre dapat bekerja lintas VM.

Juga dari Steffen lagi , Meltdown dan Specter bekerja dengan kontainer, karena kontainer bergantung pada kernel host.

VM menggunakan CPU yang sebenarnya di sistem Anda dengan beberapa instruksi istimewa yang terperangkap dan dapat diarahkan. Ia menggunakan cache dan instruksi yang sama seperti tuan rumah. Ini pada dasarnya hanyalah lapisan lain dalam CPU fisik di sistem Anda.

Virtualisasi hanya cepat karena menggunakan CPU fisik dengan abstraksi sesedikit mungkin dan bergantung pada perangkat keras CPU untuk memberikan isolasi. Hal-hal seperti qemu dapat melakukan emulasi yang akan lebih aman karena ini bukan CPU perangkat keras, tetapi jauh lebih lambat dan berbeda dari virtualisasi.

Dari pos kanonik Security.se lagi:

Spectre bekerja pada level yang berbeda dan tidak memungkinkan akses ke data ruang-kernel dari ruang pengguna. Dalam serangan ini, penyerang trik eksekusi spekulatif untuk memprediksi instruksi secara salah. Singkatnya, prediktor dipaksa untuk memprediksi hasil cabang tertentu (jika -> benar), yang menghasilkan meminta akses memori di luar batas yang biasanya diminta oleh proses korban, yang mengakibatkan eksekusi spekulatif yang salah. Kemudian dengan saluran samping, ambil nilai memori ini. Dengan cara ini, memori yang dimiliki oleh proses korban bocor ke proses jahat.

Jadi, karena VM berjalan dalam perangkat keras CPU yang sebenarnya dan yang perlu dilakukan hanyalah menjalankan loop tertentu untuk "melatih" mesin eksekusi spekulatif. Kemudian dapat menggunakan waktu yang tepat untuk menonton cache untuk pola-pola tertentu yang menunjukkan proses host atau guest (atau VM lainnya) yang ingin dieksploitasi.

Dengan cara ini berarti mesin dieksploitasi ke segala arah. Dari host ke VM, dari VM ke host, dan dari VM ke VM.

Ya, ini sama sekali tidak mudah dan merupakan hal yang sulit untuk dilakukan karena inti CPU VM dapat berubah sesuai keinginan tuan rumah dan tuan rumah dapat dengan senang hati menjadwalkan tugas pada core yang berbeda juga, tetapi selama periode waktu yang lama informasi yang cukup dapat dibocorkan untuk memberikan kunci rahasia ke beberapa sistem atau akun penting. Diberi cukup waktu dan beberapa perangkat lunak tersembunyi yang cocok semuanya berpotensi terbuka.

Jika Anda menginginkan VM "aman" maka Anda harus menjamin bahwa core-nya terisolasi. Satu-satunya cara nyata untuk memblokir serangan ini adalah dengan "memaksa" host dan VM hanya menggunakan core tertentu sehingga mereka tidak pernah berjalan pada perangkat keras yang sama tetapi ini akan mengarah pada peningkatan biaya yang efektif karena Anda tidak akan dapat memiliki banyak VM di host yang diberikan. Anda tidak akan pernah bisa melarikan diri dengan menjalankan lebih banyak VM daripada core yang tersedia, yang merupakan sesuatu yang saya harapkan dapat dilakukan pada server "beban rendah" karena banyak sistem diam selama 90% dari hidup mereka.

— Mokubai
sumber

Saya pikir Anda menafsirkan pertanyaan sebagai "jika CPU host terpengaruh, apakah VM akan terpengaruh juga?" Ketika saya mengerti pertanyaan itu, ia bertanya "jika CPU host tidak terpengaruh, apakah VM masih dapat terpengaruh?" Bisakah Anda membersihkannya?

— AndreKR

@AndreKR: saat ini semua CPU yang dieksekusi habis dipengaruhi oleh Specter; hanya dengan solusi perangkat lunak Anda dapat membuat sistem semacam aman (dan karenanya VM harus peduli tentang ini, meskipun hypervisor dapat mengisolasi para tamu dari satu sama lain jika CPU menyediakan fasilitas, misalnya barang IBRS Intel). Tetapi pada CPU dengan perintah tanpa eksekusi spekulatif, tidak ada kerentanan Spectre dalam bentuk apa pun di antara dua perangkat lunak apa pun. Esensi Spectre adalah memprovokasi eksekusi spekulatif dari sesuatu yang menempatkan data rahasia ke dalam kondisi arsitektur mikro; CPU in-order tidak.

— Peter Cordes

Yang paling menarik bukanlah eksekusi spekulatif. Hal yang paling menarik adalah bagaimana suatu proses dapat mengetahui apa yang ada dalam cache - bahkan dalam VM.

@jms serangan saluran samping yang tersedia difasilitasi dan dibuat bermanfaat oleh eksekusi spekulatif. Proses ini mungkin tidak dapat langsung membaca baris cache, tetapi eksekusi spekulatif dapat membocorkan informasi dengan melakukan perhitungan yang memasukkan nilai ke dalam cache yang dapat dideteksi atau disimpulkan oleh serangan timing. Bagian 4 dari momok kertas putih memiliki yang baik penjelasan: spectreattack.com/spectre.pdf

— Mokubai

gem5

Jika Anda tertarik mempelajari / mereproduksi kerentanan murni dengan emulasi, tanpa menggunakan host CPU, saya tidak berpikir QEMU cukup detail untuk mengamati mereka karena tidak mensimulasikan pipa CPU.

gem5 Namun, digunakan untuk memperkirakan kinerja sistem dalam penelitian dan pengembangan, dan tidak mensimulasikan internal CPU yang cukup bagi Anda untuk mengamati Specter di lingkungan yang sepenuhnya bersih dan terkendali.

Demo x86_64 keren dengan visualisasi telah diterbitkan di: http://www.lowepower.com/jason/visualizing-spectre-with-gem5.html

Kelemahan dari gem5 adalah bahwa itu jauh lebih lambat daripada QEMU simulasi lebih rinci.

— Ciro Santilli 新疆改造中心法轮功六四事件
sumber