Bir sanal makine (VM) aynı fiziksel makinede çalışan başka bir VM'yi "hackleyebilir" mi?

Sorular:

• VM bozulursa (hacklenirse), aynı fiziksel makinede çalışan diğer VM'ler için ne risk alırım?
• Aynı fiziksel ana bilgisayarda çalışan VM'ler arasında ne tür güvenlik sorunları var?
• Bu (potansiyel) zayıflıkların ve / veya sorunların bir listesi var mı (yapabilir misiniz)?

Uyarı:

Birçok sanallaştırma türünün / çözümünün olduğunu biliyorum ve farklı zayıflıkları olabilir. Ancak, çoğunlukla belirli bir satıcı hatası yerine sanallaştırma teknikleri hakkında genel güvenlik sorunları arıyorum.

Lütfen gerçek olgular, (ciddi) çalışmalar, deneyimli sorunlar veya teknik açıklamalar sağlayın. Açık ol. (Sadece) görüşünüzü vermeyin.

• Örnekler:

İki yıl önce, MMU ile ilgili güvenlik sorunları olabileceğini duydum (diğer makinelerin ana belleğine erişme, sanırım), ancak bugün itibariyle bunun pratik bir tehdit olup olmadığını bilmiyorum, ya da sadece teorik bir araştırma konu.

DÜZENLEME: Ayrıca, GnuPG başka bir VM'de çalışsa bile, L3 CPU önbelleğinden yararlanarak GnuPG gizli anahtarlarını aynı fiziksel makinede alabilen bu "Flush + Reload" saldırısını buldum. GnuPG o zamandan beri yamalı.

Elbette, çalışan bir istismar göz önüne alındığında, aynı donanım üzerinde çalışan başka bir VM'den yararlanmak mümkündür. Ek olarak, biri var olabilir. Sorunuz, son zamanlarda yapılan bir çalışmayı gösteriyor. Burada herhangi bir istismar ya da PoC paylaşmayacağım, ama nasıl yapılabileceklerini memnuniyetle söyleyeceğim.

Bu bağlamda kullanılan istismarlar, bir servisten yararlanmaya çalıştığınız makinede çalışırken çalışanlardan doğal olarak farklıdır ve artan izolasyon nedeniyle biraz daha zor olma eğilimindedir. Bununla birlikte, böyle bir istismarın gerçekleştirilmesinde kullanılabilecek bazı genel yaklaşımlar şunlardır:

• Hipervizöre saldırın . Sanal makine verilen hipervizörde yeteri kadar ayrıcalıklı bir kabuk elde edebiliyorsanız, sistemdeki herhangi bir sanal makine üzerinde kontrol sahibi olabilirsiniz. Buna yaklaşmanın yolu, sanal makineden hiper denetimciye giden ve hiper denetimciye bağımlı olan veri akışlarını aramaktır; paralel sanallaştırılmış sürücüler, pano paylaşımı, ekran çıkışı ve ağ trafiği gibi şeyler bu tür bir kanal oluşturma eğilimindedir. Örneğin, paravirtualized ağ aygıtına yapılan kötü amaçlı bir çağrı, hiper yönetici bağlamında bu trafiğin fiziksel NIC sürücüsüne iletilmesinden sorumlu rastgele kod yürütülmesine neden olabilir.
• Ana bilgisayara donanıma saldırın . Birçok cihaz ürün yazılımı güncellemelerine izin verir ve bunun için bir mekanizmaya VM'den erişilmesi mümkün olursa, niyetlerinizi destekleyen yeni ürün yazılımı yükleyebilirsiniz. Örneğin, NIC üzerindeki bellenimi güncelleme izniniz varsa, bir MAC adresi (kurbanın) için, ancak başka bir hedef MAC adresiyle (sizinki) bağlı trafiği çoğaltmanıza neden olabilirsiniz. Bu nedenle, birçok hipervizör bu tür komutları mümkün olduğunda filtreler; ESXi, bir VM'den kaynaklandıklarında CPU mikro kod güncellemelerini filtreler.
• Ana bilgisayarın mimarisine saldırın. Belirttiğiniz saldırı, esasen bir başka zamanlama tabanlı anahtar ifşa saldırısı, bunu yapar: önbellek mekanizmasının, kurban VM'nin operasyonlarında kullandığı verileri ayırt etmek için çalışma zamanlaması üzerindeki etkisini kullanır. Sanallaştırmanın özünde bileşenlerin paylaşımı vardır; bir bileşenin paylaşıldığı yerlerde, yan kanal olasılığı vardır. Aynı ana bilgisayardaki başka bir VM, kurban VM'nin bağlamında çalışırken donanımın davranışını etkileyebildiği ölçüde, kurban VM saldırgan tarafından kontrol edilir. Başvurulan saldırı, VM'nin CPU önbelleğinin (esasen paylaşılan evrensel durum) davranışını kontrol etme yeteneğini kullanır, böylece kurbanın bellek erişim süreleri eriştiği verileri daha doğru bir şekilde ortaya çıkarır; paylaşılan küresel devletin olduğu her yerde, açıklama olasılığı da mevcuttur. Örnek vermek için varsayımlara adım atmak için, ESXi'nin VMFS'sine masaj yapan ve sanal birimlerin parçalarını aynı fiziksel disk adreslerine referansta bulunduran bir saldırı ya da bir bellek balonlama sisteminin bazı belleklerin olması gerektiğinde paylaşılabileceğine inanmasını sağlayan bir saldırı düşünün özel (bu, kullanımdan sonra veya çift ayırmadan yararlanma işleminin çalışma biçimine çok benzer). Hipervizörün yok saydığı ancak erişime izin verdiği varsayımsal bir CPU MSR'yi (modele özgü kayıt) düşünün; bu, sanal makine yöneticileri arasında veri iletmek için kullanılabilir ve hipervizörün sağlaması gereken izolasyonu bozar. Ayrıca, sanal disklerin yinelenen bileşenlerinin yalnızca bir kez depolanabilmesi için sıkıştırmanın kullanılma olasılığını da göz önünde bulundurun - bir saldırganın kendi sanal yazarak ve gözlemleyerek diğer sanal disklerin içeriğini ayırt edebileceği bazı yapılandırmalarda (çok zor) bir yan kanal bulunabilir. hipervizörün yaptığı. Elbette bir hipervizörün buna karşı koruma sağlaması gerekir ve varsayımsal örnekler kritik güvenlik hataları olacaktır, ancak bazen bu şeyler geçebilir.
• Diğer VM'ye doğrudan saldırın . Mağdur VM için proksimal bir ana makineniz varsa, ana makinenin nasıl yapılandırıldığına ve erişim kontrolünü dağıtırken hangi varsayımların yapıldığına bağlı olarak rahat erişim kontrolü veya kasıtlı VM'ler arası iletişimden yararlanabilirsiniz. Bu sadece biraz alakalı, ancak bahsediyor.

Spesifik saldırılar ortaya çıkacak ve zaman geçtikçe yamanacaktır, bu nedenle belirli bir mekanizmayı sömürülebilir, yalnızca laboratuvar koşullarında sömürülebilir veya patlamaya açık olarak sınıflandırmak hiçbir zaman geçerli değildir. Gördüğünüz gibi, saldırılar dahil olma ve zor olma eğilimindedir, ancak belirli bir zamanda hangilerinin uygulanabilir olduğu hızla değişen bir şeydir ve hazırlanmanız gerekir.

Bununla birlikte, yukarıda bahsettiğim vektörler (belirli durumlarda sonuncusu hariç) sadece çıplak metal ortamlarda mevcut değildir. Yani evet, güvenlik sen istismarlara karşı koruma konusunda olduğu göz önüne alındığında yok hakkında bilmek ve olanları kamuya açıklamıştır hangi sıra çıplak metal ya da çalıştırarak biraz güvenliğini kazanabilir olarak vahşi olmadıklarını en azından hiper denetimcinin VM'leri herkes ve muhtelif kişiler için barındırmadığı bir ortamda.

Genel olarak, güvenli uygulama programlama için etkili bir strateji, bir bilgisayarda saldırgan kontrollü veya kötü amaçlı olabilecek başka işlemlerin olduğunu varsayar ve aksi takdirde böyle bir işlem yapmadığınızı düşünüyor olsanız bile istismar bilinçli programlama teknikleri kullanır. VM'nizde var. Ancak, özellikle ilk iki kategoride, donanıma ilk dokunan kişinin kazandığını unutmayın.

Teorik olarak, hayır. Hipervizörün asıl amacı sanal makineleri birbirinden izole etmektir.

Uygulamada, bir sanal makinenin aynı ana bilgisayardaki hiper denetimciyi veya diğer sanal makineleri etkilemesine izin verebilecek çeşitli hipervizörlerde güvenlik hataları olmuştur (ve gelecekte olabilir). SVirt (KVM / QEMU için) gibi güvenlik önlemleri bu sorunu çözmeyi amaçlamaktadır.

Düzenleme: Bu konunun aylar önce yapıldığını düşündüm, ama sadece yeniden canlandırıldı ve şimdi OP daha fazla 'gerçek gerçekler, alıntılanan çalışmalar' vb.

Bu türden sömürüler:

1. nadir
2. Doğada hassastır ve bu nedenle açık bir şekilde paylaşılmaz ve oldukları zaman, bu sitedeki herhangi bir kişi onları bilmeden istismarlar satıcı tarafından yamalanır.
3. Karmaşık ve satıcıya göre değişir

Bir hipervizörü kesmek ve diğer sanal makinelere erişim elde etmenin imkansız olduğunu söyleyemeyiz. Ne kadar risk olduğunu da belirleyemeyiz, ancak bu deneyim bize, hipervizör istismarlarından yararlanan birçok saldırı hikayesi bulamayacağınızı düşündüğümüzde oldukça düşük olduğunu gösteriyor.

Burada , hipervizör tabanlı birkaç saldırıdan fazlasının gerçekleştirildiğini öne süren bir tür ilginç makale var.

Bununla birlikte, hipervizörlere bağlı teknolojinin şimdi her zamankinden daha fazla olması nedeniyle, bu tür istismarlar hemen hemen tüm diğer sömürü türlerinden daha fazla aciliyetle korunacak ve korunacaktır.

IBM X-Force 2010 Yıl Ortası Eğilim ve Risk Raporundan bir alıntı:

(Lütfen bu resmi tam boyutlu olarak görüntülemek için yeni bir sekmede açın.)

Bana oldukça korkutucu gelen "Hipervizöre Kaçış" güvenlik açıklarının ölçülen yüzdesine dikkat edin. Doğal olarak raporun geri kalanını okumak istersiniz, çünkü iddiaları yedeklemek için çok daha fazla veri vardır.

İşte Playstation 3 hipervizörü üzerinde yapılan ve olası eğlenceli bir istismar hakkında bir hikaye. İşletmeniz Sony değilse, işiniz için o kadar etkili olmayabilir, bu durumda son derece etkilidir.

İşte VMware'den Eric Horschman'dan harika bir makale, burada bana bir anti-Micro $ oft olacak bir genç gibi geliyor, ama yine de iyi bir makale. Bu makalede, aşağıdaki gibi tidbits bulacaksınız:

Microsoft'un cam evinde oturanların yolumuzu atmak için başka taşları da vardı. Microsoft, ESX ve ESXi'deki konuk kopması güvenlik açığına örnek olarak CVE-2009-1244'ü işaret etti. Misafir koparma sömürüsü ciddi bir iştir, ancak Microsoft bir kez daha gerçekleri yanlış temsil etmektedir. VMware, ürünlerimizdeki bu güvenlik açığını düzeltmek için hızlı bir şekilde yanıt verdi ve ESX, Microsoft'un sizi inanmanıza neden olacağından çok daha az etkilendi:

Rakipler arasında tartışmalar. Ama muhtemelen makalenin tamamında söylediği en berrak şey şudur:

Gerçek şu ki, güvenlik açıkları ve istismarlar hiçbir kurumsal yazılım için asla tamamen ortadan kalkmayacaktır.

OpenBSD projesinin alıntılanabilir Theo de Raddt :

Aptal olmasa bile, güvenlik açıkları olmadan işletim sistemleri veya uygulamalar yazamayan dünya çapında bir yazılım mühendisleri koleksiyonunun, güvenlik delikleri olmadan sanallaştırma katmanları döndürebileceğini ve aniden yazabileceğini düşünüyorsanız, kesinlikle küstahsınız.

Biraz iltihaplı ama onun noktası iyi alındı. Teorik olarak sanallaştırmanın, sanal makineler ve sunucuları arasında tam bir izolasyon sağlaması beklenir. Uygulamada ileri saldırganlar bu korumaları ve diğer sanal makinelere kazanç erişimi ya da daha kötüsü onların ev sahibi (bkz etrafını izin ara sıra güvenlik açıkları vardır Düşmanca sanallaştırılmış ortam Hosts Güvenlik Pozlama içine Ampirik Bir Çalışma ). Ryan Ries'in belirttiği gibi, bu tür güvenlik açıkları oldukça nadirdir (bu, orada olmadıkları anlamına gelmez) ve genellikle satıcılar tarafından ifşa edilmez, ancak var olurlar.

Bu tür saldırıların potansiyelinden endişe duyuyorsanız (ve bir dereceye kadar olması gerektiğini düşünüyorum), güvenlik bölgelerini tek bir sanal ana bilgisayarda veya sanal ana bilgisayar kümesinde karıştırmamanızı öneririz. Örneğin, DMZ sanal makineleri için ayrılmış iki ana bilgisayar sanal ana bilgisayar kümesi, ara katman yazılımı için özel bir küme ve korunan varlıklar için özel bir kümeniz olacaktır. Bu şekilde, bir güvenlik açığından, bir saldırganın diğer sanal makineleri bozmasına veya hiper yöneticinin kendisini daha da kötüleştirmesine neden olacak şekilde güvenlik modeliniz bozulmadan kullanılabilir.