Hypervisor Kaçağı Bir Hata Sınıfı Değil, Bir Sözleşme İhlalidir

Zafiyet sınıflarının çoğu sizin kodunuzda bozulan bir şeyi tarif eder. Sanallaştırma izolasyon hataları ise bir önermenin bozulmasını tarif eder: inşa etmediğiniz ve içeriğine bakamadığınız bir sınırın yine de tutacağı varsayımını.

Aynı fiziksel sunucudaki bir guest'un başka bir guest'un belleğini okumasına yazmasına izin veren, ya da ayrıcalıklı yönetim alanına ulaşan bir hata çıktığında ilginç olan kısım CVE numarası değildir. Ilginç olan, o sınıra basan tüm güvenlik argümanlarının aynı anda sessizce yanlış hâle gelmesidir: çok kiracılılık iddiası, "regüle veriyi ayrı compute üzerinde izole ediyoruz" ifadesi, birbiriyle hiç konuşmamış iki müşteri arasındaki sözleşmesel ayrım, ve telafi edici kontrol olarak hypervisor'u işaret eden uyum cevabı.

Temel değerlendirme: Guest-to-host ve guest-to-guest arızaları patlama yarıçapı farklı iki ayrı problemdir ve ikisi de güvenlik programınızın normalde çalıştırdığı her kontrolün erişim alanı dışındadır. Zafiyet tarayıcınız göremez çünkü savunmasız bileşen sizin hesabınızda değildir. WAF göremez çünkü trafik kutunun dışına hiç çıkmaz. Uyum anketiniz de göremez çünkü cevap "satıcı yamalıyor"dur. Gerçekte işe yarayan kontroller; yerleştirme kararları, maruziyet azaltımı ve hangi iş yüklerinin paylaşılan silikon üzerinde hiç çalışmaması gerektiğine dair dürüst karardır.

İki Ayrı Başarısızlık Biçimi

Bu ayrımın müşterilere ve denetçilere nasıl konuştuğunuzda gerçek sonuçları vardır. Guest-to-host hatası, komşunuzun host'unuza sahip olabileceği anlamına gelir. Guest-to-guest hatası ise komşunuzun hiçbir şeyi ele geçirmeden belleğinizi okuyabileceği anlamına gelir — ki daha şaşırtıcı olan, olay sonrası mesajda en kolay hafife alınan ve çoğu zaman saldırganın asıl hedefi (bir anahtar ya da bir çıkarım) için zaten yeterli olan budur.

Düşmanca Bir Guest Gerçekte Neye Erişir

Bu sınıfın kalıcı olmasının nedeni yapısal bir asimetri: hypervisor'un saldırı yüzeyi sizin tarafınızdan girilir ve o pozisyonda guest çekirdeğini siz kontrol edersiniz, guest'un en yüksek ayrıcalık seviyesinde istediğiniz kodu yürütürsünüz, herhangi bir register durumu ve bellek yerleşimi kurarsınız ve zamanlayıcı izin verdiği hızda tekrar denersiniz. Müşteri olarak ödeme yapıyor olmanız bunu hiçbir şekilde azaltmaz.

Yüzeyler, tarihsel olarak sonuç ürettikleri sıraya yakın şekilde:

• Cihaz emülasyonu. Klasik olan. Sanal ağ kartı, sanal disk denetleyicisi, USB denetleyicisi, ekran adaptörü ve etraflarındaki firmware; saldırganın verdiği tanımlayıcıları parse eden kullanıcı alanı ya da ayrıcalıklı alan kodudur. Tek kontrol edilmemiş DMA uzunluğu ya da indis alanı, bir guest'u host bellek yazıcısına çevirir.
• Yarı-sanallaştırılmış backend'ler. virtio, xen-netback/blockback ve bunların grant table ile paylaşılan ring mekanizmaları. Bunlar I/O'yu hızlandırmak için vardır; yani guest'un verdiği indis ve referanslara bilinçli olarak güvenirler. Her gref/offset/length üçlüsü, performans baskısı altında sorulan bir sınır kontrolü sorusudur.
• Hypercall'lar ve ayrıcalıklı alan. Handler'lardaki doğrulama boşlukları, kontrol ile kullanım arasındaki TOCTOU ve yönetim alanının kendi servislerini dışarı veren büyük bir genel amaçlı işletim sistemi olması problemi.
• PCI passthrough ve SR-IOV. Bir physical function'ı guest'a vermek, ona host belleğine DMA yapma imkânı da vermek demektir. Donanım topolojisiyle gerçekten örtüşmeyen IOMMU gruplarında, ya da kendi mantığı hatalı cihazlarda bu doğrudan bir yoldur.
• Firmware, SMM ve option ROM'lar. Hypervisor'un altındaki katmanlar paylaşımdır, nadiren güncellenir ve nadiren envanterlenir. Yönetim motoru sınıfı bir problem, üstünde verdiğiniz her izolasyon garantinin altında durur.
• Mikromimari yan kanallar. Spekülatif ile cache/TLB tabanlı kanallar bellek bozulması değildir ama aynı soruya cevap verirler: güvenilmeyen komşu ne öğrenebilir. Pratik ilgisi, ortak yerleşimin planlanabilir ve öngörülebilir olmasına bağlıdır.
• Canlı göç (live migration) yolu. Göç, host'lar ve yönetim alanları arasında veri taşıyan, bütünlük varsayımları olan bir mekanizmadır. Bir güven sınırı olarak ele alın, çünkü öyledir.

Bu liste hakkında iki dürüst gözlem. Birincisi, yüzeylerin çoğu performans satın aldığı için vardır ve o performansı satın almak için bu mimariyi seçtiniz. İkincisi, bunların birçoğu modern azaltımlarla kullanıcı alanındadır; bu, çalıştığı anda izolasyon sonucunu azaltmadan sömürme ekonomisini gerçekten azaltır.

Normal Kontrolleriniz Bunu Neden Göremez

"Bulut güvenlik programımız güçlü" cümlesi bu riskin masada olduğu toplantılarda kuruluyor ve asla buna cevap vermiyor, o yüzden netleşelim.

• CSPM / bulut duruş taraması hesaplarınızın içindeki konfigürasyona bakar. Hypervisor hesaplarınızın içinde değil.
• VM'lerinizin zafiyet taraması sizin yamaladığınız şeyi bulur. Komşunuzun saldırdığı bileşeni bulmaz; bulsaydı bile onu yamalayamazdınız.
• IAM incelemesi kontrol düzlemiyle ilgilidir. Hypervisor ihlali data düzlemindedir, IAM'ın yönettiği düzemin altındadır.
• Ağ tespiti hiçbir şey görmez; komşu trafiği paket değil, bellektir.
• Guest'unuzdaki EDR, sahibi saldırganın kendisi olabilecek bir makinede çalışmaktadır. Kendisi hakkında verdiği hiçbir güvence o pozisyondan güvenilir değildir.
• Uyum haritanız büyük olasılıkla "fiziksel ve çevresel kontroller" ya da "hypervisor izolasyonu" satırını satıcı sorumluluğuna yazmıştır. Bu doğru bir cevaptır ve aynı zamanda yanlışlanamaz bir cevaptır.

Tespit yolunun yokluğu bu riskin tanımlayıcı özelliğidir. Burada izleme yaparak güvenceye ulaşamazsınız.

O Zaman Gerçekte Ne Yapılabilir

Satıcıya cevaplanabilir soruları sorun

Muğlak "kiracıları nasıl güvenceye alıyorsunuz?" soruları pazarlama üretir. Spesifik olanları kaydedebileceğiniz bir şey üretir:

1. Sanallaştırma ve host firmware hataları için güvenlik bülteni ve CVSS şiddetine bağlı bir yeniden başlatma / tahliye taahhüdünüz yayınlıyor musunuz, hedef aralık nedir?
2. Varsayılan olarak hangi cihaz modelleri ve yarı-sanallaştırılmış sürücüler açık, ve ben bunları instance'larımdan çıkarabilir ya da değiştirebilir miyim?
3. Dedicated host / dedicated instance / sole tenancy destekliyor musunuz; yerleştirme zamanlayıcı tarafından mı zorlanıyor, yoksa kayabilen bir politika tarafından mı?
4. Aynı tenant ile yeniden ortak yerleşimi önleyen bir yerleştirme afinitesi sunuyor musunuz; regüle iş yüklerinde hiç ortak yerleşimi engelleyen?
5. Hangi instance'lar canlı göç için uygun ve ben bunun dışında kalabilir miyim?
6. Mikrokod ve host firmware güncellemelerini yayınlanmış bir takvimde uyguluyor musunuz, fillo ölçeğinde yeniden başlatma ekonomisini nasıl yönetiyorsunuz?
7. GPU/SR-IOV passthrough yapılandırması değerlendirilmiş bir IOMMU düzeninde mi; bir cihaz bağlamak izolasyon hikâyemi bozar mı?
8. Instance'ımın host'unda host seviyesinde bir olay gerçekleştiğine dair bana hangi telemetriyi veriyorsunuz?

3, 4 ve 8 numaralı cevaplar risk konumunuzu gerçekten değiştirenlerdir. Gerisi evrakınızı değiştirir; onun da değeri vardır.

Kendi maruziyet yüzeyinizi daraltın

Paylaşılan altyapıda bile tenant'lar genelde kullandıklarından daha fazla kontrole sahiptir:

• Minimal açın. İhtiyacınız olmayan her emüle cihaz hâlâ erişilebilirdir. Platform izin verdiğinde sanal USB denetleyicisini, asla görüntüleme yapmadığınız grafik aygıtını ve eski bir imajla gelen firmware yığınını kaldırın.
• Metadata varsayılanını öldürün. Host ve instance seviyesindeki metadata servisleri, guest ihlalinden kontrol düzlemi kimlik bilgisi hırsızlığına giden uzun ömürlü bir köprüdür. Token zorunlu, yalnızca link-local varyantı uygulayın, container'lardan erişimi kesün ve güvenilmeyen kod çalıştıran hiçbir iş yükünün oraya ulaşmasına izin vermeyin.
• Kontrol ettiğiniz konteyner kaçağını, kontrol etmediğinizle aynı hostta çalıştırmayın. İç içe sanallaştırma, kernel modülleri, privileged container'lar, CAP_SYS_ADMIN, hostPath bağlamaları ve güvensiz seccomp/AppArmor profilleri satıcının değil sizin kodunuzdur. Çoğu tenant için "izolasyon" arızası hypervisor probleminden çok önce bir Kubernetes/düğüm problemidir.
• Ortak node pool'ların gerçekten ortak olduğunu varsayın. Yönetilen Kubernetes'te sizin pod'larınız ile başka bir müşterinin pod'ları sıklıkla aynı düğümde, aynı çekirdekte durur. Bir iş yükü için bu kabul edilemezse, o yükü dedicated node pool'a taşıyın ve bunu belgede değil zamanlayıcıda zorunlu kılın.
• Yüksek değerli veri için ortak yerleşimi bir tasarım girdisi yapın. Anahtar yönetim servisleri, HSM destekli imzalama ve ödeme yetkilendirme; sole-tenancy fiyatlandırmasının sırf iç rahatlığı için değil, maliyet üzerinden de savunulabildiği yerlerdir.

Paylaşılan silikonun basitçe yanlış cevap olduğuna nerede karar verilir

Dedicated host muğlak anlamda "daha güvenli" değildir. Saldırgan popülasyonunu değiştirir: instance alabilen her tenant yerine, host'unuzun izolasyon sınırına ulaşabilen kişi kümesi satıcının kendi operatörleri ve o spesifik donanımı satın alabilenlere küçülür. Uzun ömürlü, yüksek değerli, regüle ya da yüksek hedefli iş yükleri için doğru mimari cevap budur ve alternatiflere karşı dürüstçe fiyatlanması gerekir.

Bir Bulut Güvenliği İncelemesi Dürüstçe Neyi Test Edebilir

Sohbetin profesyonel kısmı burası. Üretimdeki bir genel bulutun hypervisor'una kasten kaçak denemesi yapmak yetkisizdir, tanımadığınız üçüncü taraflara zarar verir ve müşterinin ödeme yaptığı şey değildir. Her sağlayıcının kabul edilebilir kullanım politikası bunu söyler ve yetkin bir testçi de bunu kabul eder.

İyi bir etkinlik bunun yerine şunları yapar:

• Gerçek izolasyon yığınını ortaya koyun, sonra size ait katmanları test edin: ortamlar arası ağ bölümlemesi, IAM sınırları, kontrol düzlemi kimlik bilgisi yolları, depolama bağlama yetkilendirmesi, node ve pod güvenlik bağlamları, admission politikası ve workload identity.
• Tenant sınırını gerçekten zayıf olduğu katmanda kanıtlayın. Pratikte bu neredeyse her zaman uygulama ya da Kubernetes katmanıdır; kimlik doğrulama boşluğu, eksik bir yetkilendirme kontrolü ya da ortak cache ile kiracılar arası okma yapılabilirdir.
• Yerleştirme ve konfigürasyon iddialarını gerçekle karşılaştırın. Satın alınmış sole-tenancy ile icra edilen sole-tenancy iki farklı cümledir; inceleme hangisine sahip olduğunuzu kontrol eder.
• Metadata ve instance kimlik bilgisi maruziyetini güvenilmeyen girdi çalıştıran iş yüklerinin içinden test edin; bu meşru ve yüksek getirili bir yoldur.
• Sizin çalıştırdığınız host-komşusu yazılımları değerlendirin — ajanlar, izleme, yedekleme, node daemon'ları — çünkü sizin saldırı yüzeyiniz ile satıcınınki tam burada kesişir.
• Olay yolunu puanlayın. Satıcı yarın bir sanallaştırma düzeltmesi açıklarsa, instance'larınızın hangilerinin etkilendiğini söyleyebilir misiniz ve ne yapmanız gerekirdi? Bu hazırlık sorusu cevaplanabilir ve genelde cevaplanmamıştır.

Biri size "bulutunuzu hypervisor kaçaklarına karşı test edelim" derse, kapsamı okuyun: yukarıdaki katmanları test ediyorlar. Doğru olan bu; sadece etiketin işi karşılığına emin olun.

Hızlı Karar Tablosu

Sık Sorulan Sorular

Kendi VM'ime yönelik bir hypervisor kaçırma denemesini tespit edebilir miyim?

Gerçekçi olarak hayır, ve bu sizin araç eksiğiniz değil, bu sınıfın bir özelliği. Paylaşılan bir cihaz yolu üzerinden bellek okuma ya da yazma paket üretmez, guest içinde log üretmez, API olayı üretmez. Dolaylı olarak gözlemleyebildiğiniz host seviyesindeki operasyonel gürültüdür: beklenmedik yeniden başlatmalar, tahliye olayları, canlı göçler ya da ağır performans anomalileri. O yüzden sağlayıcınıza host olaylarından hangilerinin size açtığını sorun ve bunları olay sürecinize bağlayın.

Guest-to-guest hatası bir hypervisor kaçağından daha mı kötü?

"kötü" değil, patlama yarıçapı açısından farklılar. Guest-to-host ihlali yönetim alanını ve dolayısıyla o hosttaki her şeyi, host seviyesindeki kimlik bilgileri ve anahtarları dahil ele verir. Guest-to-guest ise komşunun hostu sahiplenmeden spesifik bir kiracının belleğini okumasına ya da bozmasına izin verir; bu daha şaşırtıcıdır, olay sonrası en kolay hafife alınır ve saldırganın asıl hedefi için çoğu zaman zaten yeterlidir.

Bir uyum sertifikası kiracı izolasyonumun gerçek olduğunu kanıtlar mı?

Hayır. Sertifikalar bir yönetim sistemini ve denetim anında doğru olan bir kontrol kümesini gösterir; çoğunlukla satıcıdan devralınan sorumluluklar işaretlenmiş hâlde. Gerçekten faydalı kanıttırlar ama bir izolasyon iddiasını yanlışlamazlar. Sertifikayı argümanınızın taşıdığı yerde, kontrolün devralınan mı, ortak mı yoksa müşteri tarafından yapılandırılan mı olduğunu bakın; üçüncü kategori gerçekten sizin sahip olduğunuz kategoridir.

Sadece dedicated host'a para versek yeter mi?

Bazen evet, ve bu bir kaygı tepkisi değil mimari karar olmalı. Dedicated host, izolasyon sınırınıza ulaşabilen kümeyi sağlayıcının operatörlerine ve o donanımı satın alabilenlere daraltır. Uzun ömürlü, yüksek değerli ya da regüle iş yükleri için bu gerçek bir azaltımdır. Ama kendi katmanlarınızı test etmenin yerine geçmez, çünkü müşterilerin fiilen yaşadığı kiracı izolasyonu arızalarının çoğu uygulama seviyesindedir, silikon seviyesinde değil.

Penetrasyon testinde burada ne kapsanmalı?

Kontrol sizin olan katmanlar: kimlik ve kontrol düzlemi kimlik bilgisi yolları, ağ bölümlemesi, depolama bağlama yetkilendirmesi, Kubernetes node ve pod güvenlik bağlamları, admission politikası, metadata servisi maruziyeti ve sizin çalıştırdığınız host ajanları. Genel bulutun hypervisor'una kasten saldırmak yetkisizdir ve hiç tanımadığınız kiracılara zarar verir; o yüzden etkinliği, sınırı gerçekten zayıf olduğu yerde kanıtlayacak ve satın aldığınız izolasyonun sahip olduğunuz izolasyon olduğunu doğrulayacak şekilde kurgulayın.

Sonraki Adım

Eresus Security bulut ortamlarını önce gerçek izolasyon yığınını haritalayarak, sonra sizin kontrol ettiğiniz sınırları ve güvendiğiniz konfigürasyon iddialarını test ederek inceler. Hangi kanıtları ürettiğimizi görmek için bulut güvenliği incelemesi ve Kubernetes güvenlik değerlendirmesi sayfalarımıza, ya da mimarinizin gerçekten bahis oynadığı katmanı konuşmak için bize ulaşın.