Meltdown & Specter - Apakah menambal kernel tamu dari hypervisor yang tidak ditambal mencegah kebocoran memori lintas-VM?

12

24 jam setelah rilis skala besar kerentanan, Rackspace diam tentang Specter dan Meltdown. Mereka tidak memiliki rencana untuk menambal semua hypervisor Xen mereka. Semua server platform baru mereka adalah server HVM, yang rentan. Server PV lama tidak rentan.

Saya telah memperbarui kernel Linux tamu HVM saya, tetapi Rackspace belum memperbarui hypervisor mereka. Akankah memperbarui kernel tamu pada hypervisor yang tidak ditonton akan mencegah VM "orang jahat" mengakses memori yang bocor dari host yang ditambal saya?

linux xen cloud-computing rackspace vulnerabilities Danny F
sumber
1
Lihat juga security.stackexchange.com/q/176709/11291
Michael Hampton

Jawaban:

12

Dari apa yang saya mengerti tentang kerentanan, tidak - serangan caching spekulatif memotong semua perlindungan CPU terhadap proses pengambilan memori dari alamat sembarang yang arbitrer.

Saya percaya ini akan mencakup tetangga VM (bahkan yang ditambal untuk melindungi terhadap serangan itu sendiri) serta ruang memori kernel hypervisor - tetapi bahkan jika ada sesuatu yang saya hilang yang akan melindungi terhadap pengungkapan memori langsung, ada juga potensi bahwa penyerang dapat menggunakan akses mereka ke memori kernel untuk mendapatkan akses yang lebih lengkap ke hypervisor.

Anda pasti tidak ingin mengambil risiko menjalankan beban kerja sensitif pada hypervisor yang tidak ditambal dalam bentuk apa pun jika Anda tidak mempercayai semua VM yang menjalankannya.

Shane Madden
sumber
6
Sederhananya: Memiliki kernel tamu yang ditambal dapat mencegah VM Anda mengakses hypervisor atau VM lain, tetapi itu tidak akan mencegah VM lain mengakses Anda!
Michael Hampton
Hai Shane, itu juga kepercayaan saya. Apakah Anda memiliki dokumentasi untuk mendukungnya? Poin khusus tentang memori tamu yang ditambal rentan terhadap tamu lain pada perangkat keras yang sama. Terima kasih.
Danny F
2
@DannyF Referensi paling langsung untuk ini yang bisa saya temukan adalah di kertas meltdown - "memori fisik dari proses lain, kernel, dan dalam hal solusi sandbox berbagi kernel (misalnya, Docker, LXC) atau Xen dalam mode paravirtualization, memori kernel (atau hypervisor), dan instance co-located lainnya "
Shane Madden
-4

Spectre dan Meltdown.

Di mana kita mulai? buruk, maksud saya siaran pers yang sangat buruk tentang sesuatu yang mungkin atau mungkin tidak mempengaruhi komputer Anda, workstation, server atau server di cloud. Ya itu benar-benar tetapi Anda harus memiliki akses lokal ke CPU yang terkait, yang mungkin PC atau Telepon tampaknya, Apple telah membuat contoh tetapi mari kita pikirkan ARM CPU, jadi itu setiap platform Mobile yang mendukung (fitur) / eksposur mikrokode / kontrol terlalu banyak atas CPU dari OS / etc / etc)

Aplikasi harus berjalan pada CPU perangkat jadi saya akan berpikir akses konsol, atau setidaknya pengguna jarak jauh yang mengakses sistem, masukkan akses perangkat ....

Pada saat ini, satu-satunya cara yang diketahui untuk mengeksploitasi kerentanan ini adalah dari lokal / langsung mengakses CPU (Sekali lagi dapat menjadi jauh setelah Anda memiliki SSH / VNC dll)

Di bawah ini adalah patch yang saya temukan sejauh ini. 

VMWare has released a security advisory for their ESXi, Workstation and Fusion products: VMSA-2018-0002
[https://www.vmware.com/us/security/advisories/VMSA-2018-0002.html][1]

RedHat has released a security advisory for their qemu product:  [https://access.redhat.com/errata/RHSA-2018:0024][1]

Amazon has released a security advisory for their Amazon Linux AMI product: ALAS-2018-939

https://alas.aws.amazon.com/ALAS-2018-939.htm l

Sekarang ini harus menjadi respons terbaik terhadap masalah yang dihadapi saat ini

Apa yang dikatakan teman BSD kita?

Google buruk; (

cek Powershell untuk hal yang sama;)

Kernel Linux Ok, kami memiliki minggu yang menarik, dan sekarang semua orang tahu mengapa kami menggabungkan semua tambalan isolasi tabel halaman x86 aneh tanpa mengikuti semua aturan waktu rilis normal.

Saya mungkin / akan kembali dan mengedit posting ini. Saya yakin non-masalah (sampai di alam liar) tidak akan menjadi masalah lama yang nyata. Google seharusnya benar-benar mengikuti tanggal rilis pengungkapan di sini! -1 untuk Google

Andrew Smalley
sumber
"Amazon Linux (AMI)" adalah distro Linux Amazon, yang terpengaruh dengan cara yang sama seperti semua sistem operasi tamu lainnya. Lebih relevan dalam konteks ini adalah aws.amazon.com/de/security/security-bulletins/AWS-2018-013 (bagian awal) untuk pengumuman EC2 (platform virtualisasi mereka), karena Anda tampaknya mencoba untuk membuat daftar solusi virtualisasi.
Håkan Lindqvist
1
Membaca dan membaca kembali ini, saya tidak percaya ini sebenarnya menjawab pertanyaan? Sebagian besar hanya kata-kata kasar tentang proses pengungkapan?
Håkan Lindqvist
Saya menghargai editorial, dan tautan untuk perbaikan, tetapi jawaban ini menyesatkan atau setidaknya membingungkan. Saya percaya ini menunjukkan bahwa skenario yang saya jelaskan akan memerlukan akses lokal ke hypervisor xenserver, yang tidak benar. Satu-satunya persyaratan adalah orang jahat memiliki VM sendiri di hypervisor yang sama dengan korban VM.
Danny F